This looks nice.
However, what happens if you have two Java processes that work on the
same index, and give it different lock directories?
They'll mess up the index.
Should we try to prevent this by not offering this option, or should we
offer it, document it well, and leave it up to the user to play by the
rules or not?
I'm leaning towards the latter, but I think some Lucene developers
would be more conservative.
Otis
--- Michael Duval <[EMAIL PROTECTED]> wrote:
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
