You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: