lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane James Vaucher <vauch...@cirano.qc.ca>
Subject Re: java.io.tmpdir as lock dir .... once again
Date Tue, 02 Mar 2004 23:37:11 GMT
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 <duval@aps.org> 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 <duval@aps.org >
> > E-Journal Programmer/Analyst
> > The American Physical Society
> > 1 Research Road
> > Ridge, NY 11961
> >
> > www.aps.org
> > 631 591 4127
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: lucene-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org


Mime
View raw message