You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@lucene.apache.org by Joseph Ottinger <jo...@enigmastation.com> on 2005/01/10 14:26:29 UTC
IndexWriter failure leaves lock in place
I'm still working through making my own directory, based on JDBC (and yes,
I know, there are some out there already, unsuitable for this reason or
that reason.)
One thing I've noticed is that the Lock procedure in IndexWriter is a
little off, I think.
My normal process on application startup is to get an IndexWriter, just to
make sure an index is there. If I get an exception (FileNotFoundException
for the FSDirectory, for example), I assume the index isn't created
properly, so then I create a new IndexWriter set to create the index.
With a file-based directory, that works well enough - and I realise there
might be a better way to do it (but I don't know it yet.)
However, the SQL-based directory leaves the lock. I think what's happening
is that the IndexWriter constructor (IndexWriter.java:216 from 1.4.3's
souce distribution) is obtaining the lock, but then the synchronized block
(starting at line 227) gets an IOException from
segmentInfos.read(directory), which throws an IOException - but the
writeLock is never explicitly removed once it's obtained.
I would think that a try/finally (or something even more predictable,
like a try/catch tht rethrows the IOException after cleanup) would be
appropriate to clear the lock *provided it's obtained* in the IndexWriter
construction, and it'd make the code that I typically use work regardless
of the specific directory I rely on.
Now, to be sure, I'm VERY FAR from a Lucene expert; am I missing
something? (I can contribute a patch if you'd like.)
-----------------------------------------------------------------------
Joseph B. Ottinger http://enigmastation.com
IT Consultant joeo@enigmastation.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: IndexWriter failure leaves lock in place
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 10, 2005, at 8:48 AM, Joseph Ottinger wrote:
> On Mon, 10 Jan 2005, Erik Hatcher wrote:
> Would the change still be valid, though, just to catch morons who do
> what
> I did?
Someone more familiar with the underlying lock infrastructure will have
to evaluate that.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: IndexWriter failure leaves lock in place
Posted by Joseph Ottinger <jo...@enigmastation.com>.
On Mon, 10 Jan 2005, Erik Hatcher wrote:
> On Jan 10, 2005, at 8:26 AM, Joseph Ottinger wrote:
> > With a file-based directory, that works well enough - and I realise
> > there
> > might be a better way to do it (but I don't know it yet.)
>
> How about using IndexReader.indexExists() instead?
>
*blank stare* .. uh... because I didn't know it was there to look for it?
:) :) :) Thanks.
Would the change still be valid, though, just to catch morons who do what
I did?
-----------------------------------------------------------------------
Joseph B. Ottinger http://enigmastation.com
IT Consultant joeo@enigmastation.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: IndexWriter failure leaves lock in place
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 10, 2005, at 8:26 AM, Joseph Ottinger wrote:
> My normal process on application startup is to get an IndexWriter,
> just to
> make sure an index is there. If I get an exception
> (FileNotFoundException
> for the FSDirectory, for example), I assume the index isn't created
> properly, so then I create a new IndexWriter set to create the index.
>
> With a file-based directory, that works well enough - and I realise
> there
> might be a better way to do it (but I don't know it yet.)
How about using IndexReader.indexExists() instead?
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: IndexWriter failure leaves lock in place
Posted by Daan Hoogland <da...@asml.com>.
Joseph (and others),
I'm not an expert on lucene either. Your mail just rang a bell and I
thought I'd contribute the ring for any expert to use. I have found
stale locks on a system running on solaris/iplanet with the FSDirectory.
The same code does not pose a problem on a windows/apache/tomcat
environment. I cannot reproduce the problem yet, and I'm not sure if it
is new to version 1.4 (the system has been running with lucene 1.2 before).
Joseph Ottinger wrote:
>I'm still working through making my own directory, based on JDBC (and yes,
>I know, there are some out there already, unsuitable for this reason or
>that reason.)
>
>One thing I've noticed is that the Lock procedure in IndexWriter is a
>little off, I think.
>
>My normal process on application startup is to get an IndexWriter, just to
>make sure an index is there. If I get an exception (FileNotFoundException
>for the FSDirectory, for example), I assume the index isn't created
>properly, so then I create a new IndexWriter set to create the index.
>
>With a file-based directory, that works well enough - and I realise there
>might be a better way to do it (but I don't know it yet.)
>
>However, the SQL-based directory leaves the lock. I think what's happening
>is that the IndexWriter constructor (IndexWriter.java:216 from 1.4.3's
>souce distribution) is obtaining the lock, but then the synchronized block
>(starting at line 227) gets an IOException from
>segmentInfos.read(directory), which throws an IOException - but the
>writeLock is never explicitly removed once it's obtained.
>
>I would think that a try/finally (or something even more predictable,
>like a try/catch tht rethrows the IOException after cleanup) would be
>appropriate to clear the lock *provided it's obtained* in the IndexWriter
>construction, and it'd make the code that I typically use work regardless
>of the specific directory I rely on.
>
>Now, to be sure, I'm VERY FAR from a Lucene expert; am I missing
>something? (I can contribute a patch if you'd like.)
>
>-----------------------------------------------------------------------
>Joseph B. Ottinger http://enigmastation.com
>IT Consultant joeo@enigmastation.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
>
>
>
--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org