Hmm when I run "ant test-lock-factory" on linux it sometimes passes
and sometimes fails. I even up'd the count to 20000 and ... it still
sometimes passes. Not sure why. I do see the two clients printing
out X% done, interleaved ... oh I see, we set delay to 1 msec; if I
change that to 0 it always fails!
Can we remove this delay option (just don't sleep)? If you want to
have some confidence locking is working, you should fully stress it
Should we use lockedID=-1 for the "no lock held" case? What if a
client id is 0? Won't this confuse LockVerifyServer?
As we bind and listen on 127.0.0.1 there is no need to pass the host to the lock verifier.
Now how will Mike be able to test NFS
Can we put back host/IP interface?
I think it's useful to validate your locking is working OK if you
store the Lucene index on a remote filesystem and you "rely" on this
locking to pick a machine to write to the index. Admittedly this is
not a recommended way to use Lucene... but at least this tool (today)
can be used to make sure locking is working if you do so... we can
still set it to 127.0.0.1 in build.xml to keep Uwe's firewall happy.
It would be better if we didn't fix the port the server binds to?
I think it's sort of weird to add the complexity of the timeouts to
the server, the waiting to make sure server is started, etc.: you can
just start the server first, see it's started, then spawn children;
ie, it seems like we are pushing complexity down into the tester
tools just to workaround limitations of ant's sub-process
handling... vs just letting Python handle this.
But I like the other cleanups like try-with-resources.