Re: IllegalStateEx thrown when calling close

ahh, yes, sorry, the ability to read is occasionally handy... [wipes egg off forehead] cheers, jed. Michael McCandless wrote: Actually, yes in 2.3.2: IndexReader.unlock has existed for a long time. In 2.4.0, we moved this to IndexWriter.unlock. Mike Jed Wesley-Smith wrote: not in 2.3.2

Re: IllegalStateEx thrown when calling close

Thanks Mike! Michael McCandless wrote: OK I'll add that (what IW does on setting an OOME) to the javadocs. Mike Jed Wesley-Smith wrote: Mike, regarding this paragraph: "To workaround this, on catching an OOME on any of IndexWriter's methods, you should 1) forcibly remove

Re: IllegalStateEx thrown when calling close

int and stays there) and need to discard it. I am suggesting that this could be documented as it is not immediately obvious without coming across it and debugging it. That being said, the VM is probably not that useful once OOMEs are flying around anyway :-) cheers, jed. Michael McCandless

Re: IllegalStateEx thrown when calling close

not in 2.3.2 though. cheers, jed. Michael McCandless wrote: Or you can use IndexReader.unlock. Mike Jed Wesley-Smith wrote: Michael McCandless wrote: To workaround this, on catching an OOME on any of IndexWriter's methods, you should 1) forcibly remove the write lock (IndexWriter.u

Re: IllegalStateEx thrown when calling close

Michael McCandless wrote: To workaround this, on catching an OOME on any of IndexWriter's methods, you should 1) forcibly remove the write lock (IndexWriter.unlock static method) IndexWriter.unlock(*) is 2.4 only. Use the following instead: directory.makeLock(IndexWriter.WRITE_LOCK_NAME)

Re: IllegalStateEx thrown when calling close

Mike Jed Wesley-Smith wrote: Michael, https://issues.apache.org/jira/browse/LUCENE-1429 Thanks mate. I'll try and work out the client handling policy of the IndexWriter calls. I see that flush now aborts the transaction as well... cheers, jed. Michael McCandless wrote: Woops, you'

Re: IllegalStateEx thrown when calling close

Michael, https://issues.apache.org/jira/browse/LUCENE-1429 Thanks mate. I'll try and work out the client handling policy of the IndexWriter calls. I see that flush now aborts the transaction as well... cheers, jed. Michael McCandless wrote: Woops, you're right: this is a bug. I'll open an

IllegalStateEx thrown when calling close

All, We have seen the following stacktrace in production with Lucene 2.3.2: java.lang.IllegalStateException: abort() can only be called when IndexWriter was opened with autoCommit=false at org.apache.lucene.index.IndexWriter.abort(IndexWriter.java:2009) at org.apache.lucene.index.IndexWr

FSDirectory.close()

All, Just a quick question regarding the need to call Directory.close() (actually for an FSDirectory) and whether it is really necessary. As far as I can tell, the only implication of this is that the refCount is not decremented and therefore the FSDirectory will persist for the life of the V

Possible exceptions using IndexReader & IndexWriter

all, We're just wondering if anyone has seen any exceptions when using the IndexWriter.addDocument(...) or IndexReader.deleteDocuments(Term term) methods apart from catastrophic IOExceptions (disk full/failed etc.). Is it possible for instance that we may be able to create a document that ca

Upgrade from 1.4.3 to 1.9.1. Any problems with using existing index files?

Hello all, We are upgrading from Lucene 1.4.3 to 1.9.1, and have many customers with large existing index files. In our testing we have reused large indexes created in 1.4.3 in 1.9.1 without incident. We have looked through the changelog and the code and can't see any reason there should be a