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/06 14:31:36 UTC
Lock obtain timed out from an MDB
If this is a stupid question, I deeply apologize. I'm stumped.
I have a message-driven EJB using Lucene. In *every* case where the MDB is
trying to create an index, I'm getting "Lock obtain timed out."
It's in org.apache.lucene.store.Lock.obtain(Lock.java:58), which the user
list has referred to before - but I don't see how the suggestions there
apply to what I'm trying to do. (It's creating a lock file in /var/tmp/
properly, from what I can see, so it's not write permissions, I imagine.)
I set the infoStream in my index writer to System.out, but I don't see any
extra information.
I'm using a SQL-based Directory object, but I get the same problem if I
refer to a file directly.
Is there a way to override the Lock portably so that I can have the lock
itself managed in an RDMS? (It's a J2EE project, so relying on file access
is problematic; if the beans using lucene to write to the index are on
multiple servers, multiple locks could exist anyway.)
-----------------------------------------------------------------------
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: Lock obtain timed out from an MDB
Posted by Joseph Ottinger <jo...@enigmastation.com>.
On Thu, 6 Jan 2005, Erik Hatcher wrote:
>
> On Jan 6, 2005, at 10:41 AM, Joseph Ottinger wrote:
> > SHouldn't Lucene warn the user if they do something like this?
>
> When a user indexes a null? Or attempts to write to the index from two
> different IndexWriter instances?
>
> I believe you should get an NPE if you try index a null field value?
> No?
Well, I'd agree - the lack of an exception was rather disturbing,
considering how badly it destroyed Lucene for the application (requiring
not only restart but cleanup as well.)
I don't know Lucene well enough to say "according to the code..." but NOT
adding the null managed to correct the problem entirely.
-----------------------------------------------------------------------
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: Lock obtain timed out from an MDB
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Jan 6, 2005, at 10:41 AM, Joseph Ottinger wrote:
> SHouldn't Lucene warn the user if they do something like this?
When a user indexes a null? Or attempts to write to the index from two
different IndexWriter instances?
I believe you should get an NPE if you try index a null field value?
No?
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Lock obtain timed out from an MDB
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Well, I think I isolated the problem: stupid error on my part, I think. I
was adding an indexed field that had, um, a value of null. Correcting that
made the process go much more properly - although note that I haven't
scaled up to have multiple elements to index. Good milestone, though.
SHouldn't Lucene warn the user if they do something like this?
On Thu, 6 Jan 2005, Erik Hatcher wrote:
> Do you have two threads simultaneously either writing or deleting from
> the index?
>
> Erik
>
> On Jan 6, 2005, at 9:27 AM, Joseph Ottinger wrote:
>
> > Sorry to reply to my own post, but I now have a greater understanding
> > of
> > PART of my problem - my SQLDirectory is not *quite* right, I think. So
> > I'm
> > rolling back to FSDirectory.
> >
> > Now, I have a servlet that writes to the filesystem to simplify things
> > (as
> > I'm not confident enough to debug the RDMS-based directory yet. That's
> > a
> > task for later, I think). The servlet says it successfully creates the
> > index like so:
> >
> > try {
> > open the index with create=false
> > } catch (file not found) {
> > open the index with create=true
> > }
> > index.optimize();
> > index.close();
> >
> > Now, when I fire off any messages to the MDB, it yields the following:
> >
> > java.io.IOException: Lock obtain timed out:
> > Lock@/var/tmp/lucene-d6b0a3281487d1bc4d169d00426f475d-write.lock
> > at org.apache.lucene.store.Lock.obtain(Lock.java:58)
> >
> > Now, this is on only two messages to the MDB, not just a flood of
> > messages. Two handlers, so I expect a lock in one's case, but not the
> > first MDB call - it should be the one causing the lock for the second
> > one,
> > if a lock exists at all.
> >
> > I've verified that when the servlet that initializes the index runs, a
> > lock file is NOT present, but again, it looks like every message fired
> > through looks for a lock and finds one, when I would think it wouldn't
> > be
> > there.
> >
> > What am I not understanding?
> >
> > On Thu, 6 Jan 2005, Joseph Ottinger wrote:
> >
> >> If this is a stupid question, I deeply apologize. I'm stumped.
> >>
> >> I have a message-driven EJB using Lucene. In *every* case where the
> >> MDB is
> >> trying to create an index, I'm getting "Lock obtain timed out."
> >>
> >> It's in org.apache.lucene.store.Lock.obtain(Lock.java:58), which the
> >> user
> >> list has referred to before - but I don't see how the suggestions
> >> there
> >> apply to what I'm trying to do. (It's creating a lock file in
> >> /var/tmp/
> >> properly, from what I can see, so it's not write permissions, I
> >> imagine.)
> >>
> >> I set the infoStream in my index writer to System.out, but I don't
> >> see any
> >> extra information.
> >>
> >> I'm using a SQL-based Directory object, but I get the same problem if
> >> I
> >> refer to a file directly.
> >>
> >> Is there a way to override the Lock portably so that I can have the
> >> lock
> >> itself managed in an RDMS? (It's a J2EE project, so relying on file
> >> access
> >> is problematic; if the beans using lucene to write to the index are on
> >> multiple servers, multiple locks could exist anyway.)
> >>
> >> ----------------------------------------------------------------------
> >> -
> >> 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
> >>
> >
> > -----------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-user-help@jakarta.apache.org
>
-----------------------------------------------------------------------
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: Lock obtain timed out from an MDB
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
Do you have two threads simultaneously either writing or deleting from
the index?
Erik
On Jan 6, 2005, at 9:27 AM, Joseph Ottinger wrote:
> Sorry to reply to my own post, but I now have a greater understanding
> of
> PART of my problem - my SQLDirectory is not *quite* right, I think. So
> I'm
> rolling back to FSDirectory.
>
> Now, I have a servlet that writes to the filesystem to simplify things
> (as
> I'm not confident enough to debug the RDMS-based directory yet. That's
> a
> task for later, I think). The servlet says it successfully creates the
> index like so:
>
> try {
> open the index with create=false
> } catch (file not found) {
> open the index with create=true
> }
> index.optimize();
> index.close();
>
> Now, when I fire off any messages to the MDB, it yields the following:
>
> java.io.IOException: Lock obtain timed out:
> Lock@/var/tmp/lucene-d6b0a3281487d1bc4d169d00426f475d-write.lock
> at org.apache.lucene.store.Lock.obtain(Lock.java:58)
>
> Now, this is on only two messages to the MDB, not just a flood of
> messages. Two handlers, so I expect a lock in one's case, but not the
> first MDB call - it should be the one causing the lock for the second
> one,
> if a lock exists at all.
>
> I've verified that when the servlet that initializes the index runs, a
> lock file is NOT present, but again, it looks like every message fired
> through looks for a lock and finds one, when I would think it wouldn't
> be
> there.
>
> What am I not understanding?
>
> On Thu, 6 Jan 2005, Joseph Ottinger wrote:
>
>> If this is a stupid question, I deeply apologize. I'm stumped.
>>
>> I have a message-driven EJB using Lucene. In *every* case where the
>> MDB is
>> trying to create an index, I'm getting "Lock obtain timed out."
>>
>> It's in org.apache.lucene.store.Lock.obtain(Lock.java:58), which the
>> user
>> list has referred to before - but I don't see how the suggestions
>> there
>> apply to what I'm trying to do. (It's creating a lock file in
>> /var/tmp/
>> properly, from what I can see, so it's not write permissions, I
>> imagine.)
>>
>> I set the infoStream in my index writer to System.out, but I don't
>> see any
>> extra information.
>>
>> I'm using a SQL-based Directory object, but I get the same problem if
>> I
>> refer to a file directly.
>>
>> Is there a way to override the Lock portably so that I can have the
>> lock
>> itself managed in an RDMS? (It's a J2EE project, so relying on file
>> access
>> is problematic; if the beans using lucene to write to the index are on
>> multiple servers, multiple locks could exist anyway.)
>>
>> ----------------------------------------------------------------------
>> -
>> 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
>>
>
> -----------------------------------------------------------------------
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-user-help@jakarta.apache.org
Re: Lock obtain timed out from an MDB
Posted by Joseph Ottinger <jo...@enigmastation.com>.
Sorry to reply to my own post, but I now have a greater understanding of
PART of my problem - my SQLDirectory is not *quite* right, I think. So I'm
rolling back to FSDirectory.
Now, I have a servlet that writes to the filesystem to simplify things (as
I'm not confident enough to debug the RDMS-based directory yet. That's a
task for later, I think). The servlet says it successfully creates the
index like so:
try {
open the index with create=false
} catch (file not found) {
open the index with create=true
}
index.optimize();
index.close();
Now, when I fire off any messages to the MDB, it yields the following:
java.io.IOException: Lock obtain timed out:
Lock@/var/tmp/lucene-d6b0a3281487d1bc4d169d00426f475d-write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:58)
Now, this is on only two messages to the MDB, not just a flood of
messages. Two handlers, so I expect a lock in one's case, but not the
first MDB call - it should be the one causing the lock for the second one,
if a lock exists at all.
I've verified that when the servlet that initializes the index runs, a
lock file is NOT present, but again, it looks like every message fired
through looks for a lock and finds one, when I would think it wouldn't be
there.
What am I not understanding?
On Thu, 6 Jan 2005, Joseph Ottinger wrote:
> If this is a stupid question, I deeply apologize. I'm stumped.
>
> I have a message-driven EJB using Lucene. In *every* case where the MDB is
> trying to create an index, I'm getting "Lock obtain timed out."
>
> It's in org.apache.lucene.store.Lock.obtain(Lock.java:58), which the user
> list has referred to before - but I don't see how the suggestions there
> apply to what I'm trying to do. (It's creating a lock file in /var/tmp/
> properly, from what I can see, so it's not write permissions, I imagine.)
>
> I set the infoStream in my index writer to System.out, but I don't see any
> extra information.
>
> I'm using a SQL-based Directory object, but I get the same problem if I
> refer to a file directly.
>
> Is there a way to override the Lock portably so that I can have the lock
> itself managed in an RDMS? (It's a J2EE project, so relying on file access
> is problematic; if the beans using lucene to write to the index are on
> multiple servers, multiple locks could exist anyway.)
>
> -----------------------------------------------------------------------
> 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
>
-----------------------------------------------------------------------
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