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 t
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 the write lock
(I
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 though.
cheers,
jed.
Michael McCandless wrote:
Or you can use IndexReader.unlock.
Mike
Jed Wesley-Smith wrote:
Michael McCa
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 the write lock
(IndexWriter.unlock static method) and then
Mike,
regarding this paragraph:
"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) and then 2) not call any methods on
the old writer. Even if the old writer has concurrent merges running,
the
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.unlock
Jed Wesley-Smith wrote:
Yeah, I saw the change to flush(). Trying to work out the correct
strategy for our IndexWriter handling now. We probably should not be
using autocommit for our writers.
autoCommit=true is deprecated as of 2.4.0, and will go away when we
finally get to 3.0, so I th
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.unlock static method)
IndexWriter.unlock(*) is 2.4 only.
Use the fo
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)
Yeah, I saw the change to flush(). Trying to work out the correct
strategy for our IndexWriter handling now. We probably should not be
using autocommit for our writers.
It was brought up by others that the OutOfMemoryError handling
requirements are a fairly strong part of the contract now - bu
Sorry I forgot to follow up with the issue, but yup that's the one.
I did also fix IW to disallow flush after it has seen an OOME.
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
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
Woops, you're right: this is a bug. I'll open an issue, fold in your
nice test case & fix it. Thanks Jed!
On hitting OOM, IndexWriter marks that its internal state (buffered
documents, deletions) may be corrupt and so it rollsback to the last
commit instead of flushing a new segment.
To worka
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
14 matches
Mail list logo
