Just to bring closure on this issue... after numerous iterations with
Marcelo, adding diagnostics to Lucene to isolate the cause of this
exception, it turns out that it's a bug in Oracle 11g's JRE.
Marcelo worked it down to a single document, which when added to a new
index, would hit the except
I didn't see any attachments on this email? (I was expecting
the .trc file so I could look at the full infoStream output).
Mike
Marcelo Ochoa wrote:
Hi Michael:
First thanks a lot for your time.
See comments below.
Is there any way to capture & serialize the actual documents being
a
Hi Michael:
First thanks a lot for your time.
See comments below.
> Is there any way to capture & serialize the actual documents being
> added (this way I can "replay" those docs to reproduce it)?
Documents are a column VARCHAR2 from all_source Oracle's System
view, in fact is a table as:
c
Is there any way to capture & serialize the actual documents being
added (this way I can "replay" those docs to reproduce it)?
Are you using threads? Is autoCommit true or false?
Are you using payloads?
Were there any previous exceptions in this IndexWriter before flushing
this segment? Coul
Hi Mike:
Well the problem is consitently, but to test the code and the
project its necesary an Oracle 11g database :(
I don't know why the computation of bufferUpto variable is wrong in
the last step, during all other calls pool.buffers.length is
consitently to 366 so I asume that its OK. And t
Hi Marcelo,
Hmmm something is not right.
Somehow the byte slices, which DocumentsWriter uses to hold the
postings in RAM, became corrupt.
Is this easily reproduced?
Mike
Marcelo Ochoa wrote:
Hi Lucene experts:
I am working upgrading Lucene-Oracle integration project to latest
Lucene 2.
Hi Lucene experts:
I am working upgrading Lucene-Oracle integration project to latest
Lucene 2.3.1 code.
After correcting a minor issue on OJVMDirectory file implementation I
have the integration running with latest 2.3.1 code.
But it only works with small indexes, I think index which are lower
