Right,
I've even inserted printf's everywhere, and it still fails as much as it
succeeds on the reloaders.
After touch() the lastModified() reported by touch() is indeed higher (1
second, to be precise).
In the containsChanges() method, it still has the old value, DESPITE
containsChanges() being called way after touch(). Apparently the update
is not propagated somehow.
So?
I checked out the source code in OpenJDK. Apparently it all comes down
to the implementation of getLastModifiedTime(fileHandle) in the
FileSystem class, which is a native method.
Until the native method is called, there is no trace of caching of any kind.
I don't know if Ubuntu uses a custom implementation here, but the
default implementation for unix like systems seems to simply call stat()
or stat64().
So it seems the Java implementation is correct. That leaves two
possibilities
- the native implementation in Ubuntu uses caching.
- the stat or stat64 in the Ubuntu version of the kernel uses caching.
Perhaps we could just "solve" the issue by waiting 100 ms or something
after updating the time? It's ugly, but if it works...
Tom.
Op 27-10-2010 2:42, Tom van Dijk schreef:
Hi there,
Initial code inspection doesn't show any obvious problems.
In fact, the only thing I can think of is that touch might be bugged
somehow on Ubuntu systems, or that perhaps another
fireUpdateCheck(registry); should be added before the first touch, to make
sure the "last modifiedTime()" is populated...
The "funny" thing is that at the surface it seems there's not much
multithreading going on... but if we'd somehow tweak touch to wait an extra
second or so, this might as well kill any possible multithreading issues,
making us believe we solved the issue.
I'm also wondering whether the warning that sometimes appears that there's
a registry active "somewhere" is related to this problem, but perhaps
that's just caused by the test failing and the registry not being shut down
because of the fail.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
