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. from 2008.
Best regards
Ralf
Am 13.01.14 21:15, schrieb Michael McCandless:
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 yet exposed through Solr) performance
shouldn't change much for optimized vs unoptimized indices.
Mike McCandless
http://blog.mikemccandless.com
On Mon, Jan 13, 2014 at 10:09 AM, Ralf Matulat
<ralf.matu...@bundestag.de> wrote:
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 - 20081027_AB)
JCL - 20090218_01
A question regarding to optimizing the index:
As of SOLR 3.X we encountered massive performance improvements with facettet
queries after optimizing an index. So we once started optimizing the indexes
on a daily basis.
With SOLR 4.X and the new index-format that is not true anymore?
Btw: The checkIndex failed with 'java.io.FileNotFoundException:', I guess
because I did not stopped the tomcat while checking. So SOLR created, merged
and deleted some segments while checking. I will restart the check after
stoppimg SOLR.
Kind regards
Ralf Matulat
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
(curBuf.get(b, offset, len)). Such page-spanning reads are very rare.
The code looks fine to me though, and it's hard to explain how NPE (b
= null) could happen: that byte array is allocated in the
Lucene41PostingsReader.BlockDocsAndPositionsEnum class's ctor: encoded
= new byte[MAX_ENCODED_SIZE].
Separately, you really should not have to optimize daily, if ever.
Mike McCandless
http://blog.mikemccandless.com
--
Ralf Matulat
Deutscher Bundestag
Platz der Republik 1
11011 Berlin
Referat IT 1 - Anwendungsadministration
ralf.matu...@bundestag.de
Tel.: 030 - 227 34260
