Michael:
Yep, previous implementation have his own buffer to reduce BLOB IO
overriding Input/OutputBufferStream base classes.
Now Input/Output stream classes use BufferStream implementation and
only implement flushInternal and setSize methods among others minimun
changes :)
Best regards, Marc
I'm glad to hear this!
But: what was the root cause of the problems? Why didn't your
previous Input/Output implementations, which worked with Lucene 2.3,
work win 2.4? It's kinda spooky.
Mike
Marcelo Ochoa wrote:
Michael:
I have OJVMDirectory working with 2.4rc2 code base.
I have re
Michael:
I have OJVMDirectory working with 2.4rc2 code base.
I have refactored Output and Input streams classes according to
latest implementation of Buffered base classes and works OK.
All of my tests suites runs OK also the bug in the 11g JITs compiler
is not reproducible.
I'll test this
| +46 765 27 19 55 | [EMAIL PROTECTED] |
www.mogul.com
> -Original Message-
> From: Marcelo Ochoa [mailto:[EMAIL PROTECTED]
> Sent: den 26 september 2008 20:54
> To: java-user@lucene.apache.org
> Subject: [SPAM] - Re: Caused by: java.io.IOException: read
> past EOF on Sl
Marcelo,
Do you have any sense whether this is an issue with your integration
(eg your Directory implementation that stores data in BLOB columns) vs
something with Lucene 2.4?
It seems odd to me that there would be a bug in your Directory
implementation that 2.3 didn't tickle but 2.4 did
I will try the other stuff and will let you know.
This is how we do the search ,
we will get the Hits in one call and we will make another call to get the
data from lucene.
My guess is when it gets the matching Hits it getting from master and when
it tries to retrieve the actual data its hittin
Mike:
Actually there is more issues at first glance with OJVMDirectory integration.
Note this, I am creating an index with two simple documents:
INFO: Performing: SELECT /*+ DYNAMIC_SAMPLING(0) RULE NOCACHE(T1) */
T1.rowid,F1,extractValue(F2,'/emp/name/text()')
"name",extractValue(F2,'/emp/@id'
Which version of Lucene is this? Looks like 2.3.x -- what's the x?
Can you run your app server with assertions enabled for
org.apache.lucene.*? It may catch something sooner.
Can you try running CheckIndex after the snapshot is produced, just to
see if there is any corruption?
Your fir
This one looks spooky!
Is it easily repeated? If you could print out which 2 terms you had
tried to delete, and then zip up the index just before deleting those
docs (after closing the writer) and send to me, I can try to
understand what's wrong with the index. It looks as if the *.tis f
The following are steps..
1.We do indexing every 5 minutes on master and when indexing is done a
snapshot is taken
2. On slave we have a cronjob which runs snappuller every 3 minutes to check
for new snapshots and installs it on slave if it finds new one
3.Master and Slave are continuously serv
Michael:
I just start testing 2.4rc2 running inside OJVM.
I found a similar stack trace during indexing:
IW 3 [Root Thread]: flush: segment=_3 docStoreSegment=_3
docStoreOffset=0 flushDocs=true flushDeletes=true flushDocStores=false
numDocs=2 numBufDelTerms=2
IW 3 [Root Thread]: index before
Can you describe the sequence of steps that your replication process
goes through?
Also, which filesystem is the index being accessed through?
Mike
rahul_k123 wrote:
First of all, thanks to all the people who helped me in getting the
lucene
replication setup working and right now its
First of all, thanks to all the people who helped me in getting the lucene
replication setup working and right now its live in our production :-)
Everything working fine, except that i am seeing some exceptions on slaves.
The following is the one which is occuring more often on slaves
at java
13 matches
Mail list logo
