Sounds like it's a hotspot bug.
AFAIK, hotspot doesn't just compile a method once... it can do
optimization over time.
To work around it, have you tried pre previous version: 1.5_05?
It's possible it's a fairly new bug. We've been running with that
version and Lucene 1.4.3 without problems (on Opteron, RHEL4).
You could also try the latest Lucene 1.9 to see if that changes enough
to avoid the bug.
-Yonik
On 12/11/05, Dan Gould <[EMAIL PROTECTED]> wrote:
> First, thank you Chris, Yonik, and Dan for your ideas as to what might be
> causing this problem.
>
> I tried moving things around so that the IndexReader is still open when it
> calls TermFreqVector.getTerms()/TermFreqVector.getTermFrequencies(). It
> didn't seem to make any difference.
>
> I also tried running Java with the flags:
> -Xmx2048m -XX:MaxPermSize=200m
> (the box has 4GB of RAM) and it still crashes. It's hard to tell, but the
> program does seem to run for a lot longer (maybe 10 hours), but that could
> just be randomness in my tests.
>
> The JVM always seems to crash with
>
> Current CompileTask:
> opto:1836
> org.apache.lucene.index.IndexReader$1.doBody()Ljava/lang/Object;
> (99 bytes)
>
> which in the Lucene source is:
>
> private static IndexReader open(final Directory directory, final boolean
> closeDirectory) throws IOException {
> synchronized (directory) { // in- & inter-process
> sync
> return (IndexReader)new Lock.With(
> directory.makeLock(IndexWriter.COMMIT_LOCK_NAME),
> IndexWriter.COMMIT_LOCK_TIMEOUT) {
> public Object doBody() throws IOException {
> SegmentInfos infos = new SegmentInfos();
> infos.read(directory);
> if (infos.size() == 1) { // index is optimized
> return SegmentReader.get(infos, infos.info(0),
> closeDirectory);
> }
> IndexReader[] readers = new IndexReader[infos.size()];
> for (int i = 0; i < infos.size(); i++)
> readers[i] = SegmentReader.get(infos.info(i));
> return new MultiReader(directory, infos, closeDirectory,
> readers);
>
> }
> }.run();
> }
> }
>
> that's definitely a non-trivial bit of code, but I can't imagine that
> there's a problem that I'm seeing that no one else else. Moreover, that
> code gets run hundreds or even thousands of times before it crashes, so I
> don't image it's being HotSpot-compiled for the first time.
>
> I'm running the 1.4.3 release and the 1.5.0_06-b05 JVM on Centos Linux on
> an Opteron.
>
> Any further guesses?
>
> Thank you all very much,
> Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
