Toke Eskildsen wrote:
On Wed, 2010-02-17 at 15:18 +0100, Michael van Rooyen wrote:
I recently upgraded from version 2.3.2 to 2.9.1. [...]
Since going live a few days ago, however, we've twice had read past
EOF exceptions.
The first thing to do is check the Java version. If you're using Sun
Toke Eskildsen wrote:
On Wed, 2010-02-17 at 15:18 +0100, Michael van Rooyen wrote:
I recently upgraded from version 2.3.2 to 2.9.1. [...]
Since going live a few days ago, however, we've twice had read past EOF
exceptions.
The first thing to do is check the Java version. If you're usin
On Wed, 2010-02-17 at 15:18 +0100, Michael van Rooyen wrote:
> I recently upgraded from version 2.3.2 to 2.9.1. [...]
> Since going live a few days ago, however, we've twice had read past EOF
> exceptions.
The first thing to do is check the Java version. If you're using Sun JRE
1.6.0, you might h
Ok. Just to followup, I performed the same steps with another of our indexes
and did not have the same issue:
Opening index @ /lucenedata/index4
Segments file=segments_85 numSegments=1 version=FORMAT_HAS_PROX [Lucene 2.4]
1 of 1: name=_42 docCount=3986767
compound=true
hasProx=true
Hi:
Could you try open the index using Luke but using the JDK bundled
with the Oracle DB?
I mean, try to use Luke as an standalone application in the same
machine but outside the OJVM using the JDK at:
$ORACLE_HOME/jdk
which was used to compile most of the classes running inside the OJV
Michael McCandless-2 wrote:
>
> That exception seems to indicate that the fdx file being opened by
> FieldsReader is 0 length (it's trying to read the first int from that
> file).
>
> Is the exception repeatable, if you try again to call
> IndexReader.open?
>
> It's odd that CheckIndex finds
Toke Eskildsen wrote:
>
> A quick check when a corrupt index problem is encountered:
> Does any of your machines run Java 1.6.0_04-1.6.0_10b25?
>
Thanks Toke.
As I mentioned in my response to Erick, this is complicated by the fact that
the error is within a java stored procedure in Oracle. Th
Erick Erickson wrote:
>
> I guess my first question, based on your statement that you ran
> checkindex from a different machine would be whether you have
> the same version of Lucene installed on both machines? And how
> did you get your index where it is now? did you optmize it in place
> or d
That exception seems to indicate that the fdx file being opened by
FieldsReader is 0 length (it's trying to read the first int from that
file).
Is the exception repeatable, if you try again to call
IndexReader.open?
It's odd that CheckIndex finds no problem with the index, but opening
an IndexR
On Tue, 2009-01-06 at 23:07 +0100, 1world1love wrote:
> Greetings all. I have an index that I have optimized and when I try to open
> the index I get this:
>
> java.io.IOException: read past EOF
A quick check when a corrupt index problem is encountered:
Does any of your machines run Java 1.6.0_04
I guess my first question, based on your statement that you ran
checkindex from a different machine would be whether you have
the same version of Lucene installed on both machines? And how
did you get your index where it is now? did you optmize it in place
or did you optimize it somewhere else and
turns out i needed a seek method.
i ended up modeling it after the RAM Directory.
i turned the RAMFile into an @Entity.
the directory accesses the EntityManager.
and i am using JBossCache.
preliminary testing shows comparable response times.
John Gilbert <[EMAIL PROTECTED]> wrote on 14/10/2006 20:14:43:
> I am trying to write an Ejb3Directory. It seems to work for index
> writing but not for searching.
> I get the EOF exception. I assume this means that either my
> OutputStream or InputStream is doing
> something wrong. It fails becaus
I see some mentions of NoOpDirectory, as in
http://www.gossamer-threads.com/lists/lucene/java-user/14064?search_string=read%20past%20EOF;#14064
which point to the Lucene bug tracker. I just searched the Lucene JIRA and
didn't find anything related to NoOpDirectory. Any clues?
_
14 matches
Mail list logo
