Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Monitor against individual file timestamp changes instead of System/currentTimeMillis #3

Closed
CmdrDats opened this issue Aug 17, 2012 · 3 comments · Fixed by #6
Closed

Comments

@CmdrDats
Copy link
Contributor

I would like to make a change so that when ns-tracker is initially run, it finds all the namespaces and records their current timestamps into a map and uses each individual entry to check for timestamp changes instead of using the current timestamp atom.

My specific case is that I'm working off an NFS connection to a VM and the dates keep getting out of sync with my machine so it doesn't pick up the changes.

How do you feel about this? Would it be valuable being able to select whether you want the lighter System/currentTimeMillis strategy or the map checking strategy?

@weavejester
Copy link
Owner

Wouldn't a difference in system clock times just result in a slight delay, or am I wrong?

@CmdrDats
Copy link
Contributor Author

If it's slightly ahead, then yes - you only end up with a slight delay, but if it's behind it ends up not getting picked up as changed at all - of course, if the clock is two hours ahead, then it'll have a two hour delay before reloading, which isn't great.

Of course, this can be fixed by syncing the times correctly, but messing around with machine time differences is not a fun prospect when it's feasible for the tracking library to handle it in a more stable way so that no one ever has the issue again.

@weavejester
Copy link
Owner

Okay, that sounds reasonable. It sounds like this can be implemented with relatively little change to the source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants