It becomes just more spooky.
The optimize-run this night was succesful.
Yesterday I did two things:
1. Checked the index without any result (no problems found).
2. I did an expungeDelete on the mentioned index.
So I have no idea what is going on here.
Btw: Java version is still the old 1.6.0. f
I checked the index without any problems beeing found.
So it is not obvious, what is going wrong here while the index itself
looks okay.
Next step, updating java, is work in progress.
So I will come back after sorting out the java version as the cause for
the failing optimize.
The checkIndex
It sounds quite obvious to upgrade the java environment to go on with that.
We are updating our index almost every second and so over time it counts
up a lot of segment files (up to 32 in our case). So optimizing was
always a good idea in the SOLR 3.X world.
We regocnized that in SOLR 4.4.0 it
I have trouble understanding J9's version strings ... but, is it
really from 2008? You could be hitting a JVM bug; can you test
upgrading?
I don't have much experience with Solr faceting on optimized vs
unoptimized indices; maybe someone else can answer your question.
Lucene's facet module (not
> java -version
java version "1.6.0"
Java(TM) SE Runtime Environment (build
pxa6460sr3ifix-20090218_02(SR3+IZ43791+IZ43798))
IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Linux amd64-64
jvmxa6460-20081105_25433 (JIT enabled, AOT enabled)
J9VM - 20081105_025433_LHdSMr
JIT - r9_20081031_1330
GC
Which version of Java are you using?
That root cause exception is somewhat spooky: it's in the
ByteBufferIndexCode that handles an "UnderflowException", ie when a
small (maybe a few hundred bytes) read happens to span the 1 GB page
boundary, and specifically the exception happens on the final read
thanks otis,
index was corrupted.
On Sat, Jan 5, 2013 at 1:17 AM, Otis Gospodnetic wrote:
> Sounds like you may have a corrupt index. Try running the CheckIndex tool.
>
> Otis
> Solr & ElasticSearch Support
> http://sematext.com/
> On Jan 3, 2013 8:59 AM, "Karan jindal" wrote:
>
> > Hi everyon
Sounds like you may have a corrupt index. Try running the CheckIndex tool.
Otis
Solr & ElasticSearch Support
http://sematext.com/
On Jan 3, 2013 8:59 AM, "Karan jindal" wrote:
> Hi everyone,
>
> I have a solr index which is built using solr 3.2.
>
> I am facing two problem with that solr index.
The stack trace indicates there's an issue with optimizing. How are
you kicking off
optimizing? Is it automatic or manual?
34G for an index with that many documents does seem excessive. Are you
re-indexing the same
content with the same unique key? In other words do you have a large
number of dele
On Tuesday 15 March 2011 01:31 PM, Anurag wrote:
Do you mean that earlier it was doing indexing well then all of sudden you
started getting this exception?
-
Kumar Anurag
--
View this message in context:
http://lucene.472066.n3.nabble.com/background-merge-hit-exception-tp2680625p2680979.ht
Do you mean that earlier it was doing indexing well then all of sudden you
started getting this exception?
-
Kumar Anurag
--
View this message in context:
http://lucene.472066.n3.nabble.com/background-merge-hit-exception-tp2680625p2680979.html
Sent from the Solr - User mailing list archive
OK I opened:
https://issues.apache.org/jira/browse/LUCENE-1374
Mike
Chris Harris wrote:
I've made some changes to my Solr setup, and now I'm getting the
"background merge hit exception" pasted at the end of this message.
The most notable changes I've made are:
Update to r690989 (Lucene
In fact this (the root cause NPE) is a Lucene bug -- I have a small
test case showing it.
It can happen when you have compressed text fields (Store.COMPRESS) in
the index. I'll open an issue and fix it.
Thank you for raising this!
Mike
Chris Harris wrote:
I've made some changes to my
I found an answer: not enough space in filesystem.
Funtick wrote:
>
> Is it file-system error? I can commit and I can not optimize:
>
> Exception in thread "main" org.apache.solr.common.SolrException:
> background merge hit exception: _ztu:C14604370 _105b:C1690769
> _105l:C340280 _105w:C336330
14 matches
Mail list logo
