Andrea Aime a écrit :
> Long story short, I do believe that increasing that 50ms sleep
> to something like 200ms may cure the issue we're seeing.
> Martin, can you try that?
It worked (actually I got a random test failure elswhere in the same class -
running "mvn install" again fixed that), but it doesn't mean much since the
failure occurs randomly. I can only wait if it help in long term.
However maybe we should commit permanently the 200 ms delay instead of 50 ms.
The failure do not occurs only on my machine; it occurs also on the Continuum
build machine. We are not doing "real time" programming; if the
testGetFeatureLockingExpire() method expects some task to be done in 50 ms,
there is absolutly no garantee that it will really be done in this lap time. The
garbage collector may kick off, the OS may be swapping, a server like the
Continuum machine may be busy with something else, etc. Increasing the delay to
200 ms may help to reduce the frequency of those test failures.
> A better way to solve this problem would be to use System.nanotime
> to check lock expiry, which should far more accurate that
> currenttimeinmillis
Maybe I misunderstood the problem? I assumed that the test case was expecting
some work to be done in 50 ms, which may be not suffisient when the system is
busy with something else. If my assumption is not wrong, then a more accurate
time measurement whould not change anything?
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
