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
> >> [EMAIL PROTECTED]
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >
> > -----------------------------------------------------------------------
> > Joseph B. Ottinger http://enigmastation.com
> > IT Consultant [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]
>
-----------------------------------------------------------------------
Joseph B. Ottinger http://enigmastation.com
IT Consultant [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
