I've done something similar to configure my merge factor (but it was
outside my code), and am planning on setting the limit on boolean queries
this way as well. I think it's pretty clean especially if you use
org.apache.lucene.xxx properties with decent default values.
Adding this feature could probably better document the hazards of use an
index lock in a distributed system, considering many people like to know
the implications of running lucene in a web (and potentially replicated)
env.
my 2c,
sv
On Tue, 2 Mar 2004, Otis Gospodnetic wrote:
> 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.
If you sell people coffee, they can always burn themselves. Might as well
warn them.
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
