Hi,
Kindly provide your inputs on the issue.
Thanks,
Modassar
On Mon, Feb 1, 2016 at 12:40 PM, Modassar Ather
wrote:
> Hi,
>
> Got following error during optimize of index on 2 nodes of 12 node
> cluster. Please let me know if the index can be recovered and how and what
> could be the reason?
It looks like your solr lucene-core version doesn't match with the
lucene version used to generate the index, as Yonik said, looks like
there is a lucene library conflict.
2009/8/19 Chris Hostetter :
>
> : how can that happen, it is a new index, and it is already corrupt?
> :
> : Did anybody else
: how can that happen, it is a new index, and it is already corrupt?
:
: Did anybody else something like this?
"Unknown format version" doesn't mean your index is corrupt .. it means
the version of LUcnee parsing the index doesn't recognize the index format
version ... typically it means you a
Wow, that is an interesting one...
I bet there is more than one Lucene version kicking around the
classpath somehow.
Try removing all of the servlet container's working directories.
-Yonik
http://www.lucidimagination.com
On Fri, Aug 7, 2009 at 4:41 AM, Maximilian
Hütter wrote:
> Hi,
>
> how can t
Robert Haschart <[EMAIL PROTECTED]> wrote:
> To answer your questions: I completely deleted the index each time
> before retesting. and the java command as shown by "ps" does show -Xbatch.
> The program is running on:
> > uname -a
> Linux lab8.betech.virginia.edu 2.6.18-53.1.14.el5 #1 SM
Michael,
Following up on this most recent post. I remembered that the initial
records were translated into utf-8 prior to indexing, whereas the
updates records are in the marc-8 encoding internally, and the program
is written to translate them on the fly as they are read in before
indexing th
Michael,
To answer your questions:
I completely deleted the index each time before retesting.
and the java command as shown by "ps" does show -Xbatch.
The program is running on:
> uname -a
Linux lab8.betech.virginia.edu 2.6.18-53.1.14.el5 #1 SMP Tue Feb 19
07:18:21 EST 2008 i686 i686 i
Hmmm, not good.
One other thing to try would be -Xint, which turns off hotspot
compilation entirely. On that last case that also prevented the issue.
Did you cleanly rebuild your index when you retested? And you're
really certain your JRE is running with -Xbatch? (You should be able
t
Mike,
You are right it does sound exactly like that situation. The java
version is:
java version "1.6.0_05"
Java(TM) SE Runtime Environment (build 1.6.0_05-b13)
Java HotSpot(TM) Server VM (build 10.0-b19, mixed mode)
Which seems to be the same as the one giving the other poster problems.
I
Which exact version of the JRE are you using? Can you try running
java with -Xbatch (forces up front compilation)?
Your situation sounds very similar to this one:
http://lucene.markmail.org/message/awkkunr7j24nh4qj
Mike
On Apr 17, 2008, at 10:57 AM, Robert Haschart wrote:
Greetings all
Maybe double check your CLASSPATHs?
Because, based on the line numbers in the exception, it really looks
like it's Lucene 2.1 that's trying to open a Lucene 2.2+ index. The
term infos file (.tii, .tis) changed from -2 -> -3 format in 2.3.
Mike
On Feb 25, 2008, at 7:19 AM, Paul Danese wro
2Unfortunately, the answer is "no". I didn't use an upgraded version of lucene
or solr. this is the bizzarre issue. I'm actually using solr via the
acts_as_solr plugin used in ruby.
At the time, I was adding a few 100-thousand docs to the index...there appears
to have been a memory leak as
did you create/modify the index with a newer version of lucene than the
one you use in solr?
In this case I doubt you can downgrade your index, but maybe you can
upgrade lucene in your solr (search in this forum, there should be a
thread about this), (or try with the latest nightly builds)
Pau
13 matches
Mail list logo
