Hello All,
I've come across my first gotcha with the system property "java.io.tmpdir" as the lock directory.
Over here at APS we run lucene in two different servlet containers on two different servers for both performance
and security reasons. One container gives read access to the collection and the other is contantly updating the collection.
The collection is NFS mounted from both servers. This worked fine until the lucene update 1.3. Now the lock files are being
written to the temp dir's in each of the respective containers root dir's. This of course breaks the locking scheme.
I could have changed the tmpdir prop to write files back into the collection directory but this would also pollute
the tmpdir with other non-related files. My solution was as follows:
I've hacked the code for the time being by updating FSDirectory and replaced all System.getProperty("java.io.tmpdir")
calls with a call to a new method "getLockDir()". This method checks for a "lucene.lockdir" prop before the
"java.io.tmpdir" prop giving the end user a bit more flexibility in where locks are stored.
Here is the method:
/** Allow flexible locking directories - Michael R. Duval 3/02/04 */
private String getLockDir() {
String lockDir; if ((lockDir = System.getProperty("lucene.lockdir")) == null)
return System.getProperty("java.io.tmpdir");
else
return lockDir;
}Hopefully a solution similar to this will make it in to one of the next distributions.
Thanks and Cheers,
Mike
-- Michael R. Duval <[EMAIL PROTECTED] > E-Journal Programmer/Analyst The American Physical Society 1 Research Road Ridge, NY 11961
www.aps.org 631 591 4127
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
