I think that's a great idea Uwe ! It will reduce the chance for collision even further.
After we've discussed this on IRC, Uwe raised an important point about why the lock file must be deleted. It is possible that two JVMs will attempt to lock the same Directory, one w/ Native and the other w/ Simple. If we won't check in obtain() whether the file exists, it might obtain a native lock, while the Directory is actually locked by another JVM using Simple. Uwe also mentioned Native was fixed in 2.9? Is that right Uwe - did I get that part correct? So, I believe the changes that should be made are: 1) Use System.nanoTime() as a seed to Random. 2) Use ManagementFactory.getRuntimeMXBean().getName() as part of the test lock name. 3) In release(), if delete() fails, check if the file indeed exists. If it is, let's attempt a re-delete() few ms later. 4) If (3) still fails, I think we should throw an exception, or attempt a deleteOnExit. What do you think? Shai On Thu, Apr 29, 2010 at 12:17 PM, Uwe Schindler <[email protected]> wrote: > A possibility to get something that does not depend on Date/Time and so on: > ManagementFactory.getRuntimeMXBean().getName() > > This returns a unique identifier of the running Java VM. On most platforms, > this contains the process ID. Maybe we should use this as an additional > information for the test file name. As it's an String and may contain > incompatible chars for a filename, maybe use the hashCode() of the returned > String. > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: [email protected] > > > > -----Original Message----- > > From: Michael McCandless [mailto:[email protected]] > > Sent: Thursday, April 29, 2010 12:01 PM > > To: [email protected] > > Subject: Re: LuceneJUnitResultFormatter sometimes fails to lock > > > > On Wed, Apr 28, 2010 at 1:52 PM, Shai Erera <[email protected]> wrote: > > > I use 1.6.0_18. > > > > > > Maybe seeding w/ System.nanoTime() will help, but don't you think > > > NativeFSLock should be more robust anyway? Even for the regular lock > > > file this can happen if at the same time delete() is attempted the > > > file is held by another process ... > > > > Oh definitely -- I think we should do both (fix the random seeding & > > the robustness fixes). > > > > Mike > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
