Good detective work ... I am wonder (if this is a test of memory
datastore) what can possibly be going on... oh wait the feature is
locked for a Duration.
The lock is only checked when it is tested, so the check should be
stable regardless of what is going on.... oh I guess we do need to wait
for the System clock to click over a notch.
Could we do a loop?
long time = System get time in milliseconds
do {
Thread.sleep( 15 );
} while( time == System get time in milliseconds );
May be a "Faster" alternative to waiting 200 milliseconds and will
protect us from hardware changes in the future.
Jody
> Jody Garnett ha scritto:
>> What kind of hardware do you run these days? Multi core?
>
> Jody, the test that is failng is:
>
> public void testGetFeatureLockingExpire() throws Exception {
> FeatureLock lock = FeatureLockFactory.generate("Timed", 1);
> FeatureLocking road = (FeatureLocking)
> data.getFeatureSource("road");
> road.setFeatureLock(lock);
> assertFalse(isLocked("road", "road.rd1"));
> road.lockFeatures(rd1Filter);
> assertTrue(isLocked("road", "road.rd1"));
> Thread.sleep(50);
> assertFalse(isLocked("road", "road.rd1"));
> }
>
> There is no concurrency whatsoever here. The only thing
> that may make it failing is the duration of the sleep itself,
> which seems to be very small. On my computer for example I apparently
> cannot measure time differences of time less than 15ms.
>
> In fact, if I change the sleep time to be less than 15ms,
> the test starts to randomly fail, and consistenly fails if I use
> less than 5ms. Mine is a windows xp box.
>
> Now, on linux kernels the kernel tick is configurable, I don't
> know the details, but it may be that timers are less accurate
> there as a result of the config_hz or the tickless kernel configation
> oprtions (I kind of remember that setting
> lower frequency was good for server side machines and for notebooks,
> whilst not so good for desktops, but my recallings are really
> confused).
>
> 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?
>
> A better way to solve this problem would be to use System.nanotime
> to check lock expiry, which should far more accurate that
> currenttimeinmillis
> (http://java.sun.com/j2se/1.5.0/docs/api/java/lang/System.html#nanoTime())
>
> but we'll be able to do so only once we switch to java 5.
>
> Cheers
> Andrea
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
