lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Loofbourrow <bloofbour...@knowledgemosaic.com>
Subject A strange Solr NullPointerException while shutting down Tomcat, possible connection to messed-up index files
Date Tue, 18 Sep 2012 22:58:53 GMT
I’m using Solr/Lucene 3.6 under Tomcat 6.



When shutting down an indexing server after much indexing activity,
occasionally, I see the following NullPointerException trace from Tomcat:



INFO: Stopping Coyote HTTP/1.1 on http-1800

Exception in thread "Lucene Merge Thread #1"
org.apache.lucene.index.MergePolicy

$MergeException: java.lang.NullPointerException

        at
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException

(ConcurrentMergeScheduler.java:509)

        at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(Conc

urrentMergeScheduler.java:482)

Caused by: java.lang.NullPointerException

        at
org.apache.lucene.index.IndexFileDeleter.refresh(IndexFileDeleter.jav

a:349)

        at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3915)

        at
org.apache.lucene.index.ConcurrentMergeScheduler.doMerge(ConcurrentMe

rgeScheduler.java:388)

        at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(Conc

urrentMergeScheduler.java:456)



Here’s where the strange part comes in. The code at the line of the “caused
by” looks like this:



      *if* (filter.accept(*null*, fileName) &&

          (segmentName == *null* || fileName.startsWith(segmentPrefix1) ||
fileName.startsWith(segmentPrefix2)) &&

          !refCounts.containsKey(fileName) &&

          !fileName.equals(IndexFileNames.*SEGMENTS_GEN*)) {



So if the line number is accurate, filter must be null. But filter is set
like this:



    IndexFileNameFilter filter = IndexFileNameFilter.*getFilter*();



And the method in IndexFileNameFilter looks like:



  *public* *static* IndexFileNameFilter getFilter() {

    *return* *singleton*;

  }



And the singleton field is initialized like so:



  *private* *static* IndexFileNameFilter *singleton* =
*new*IndexFileNameFilter();



So, that shouldn’t ever be null, right? Well, I can’t exactly repro this
rare situation in a debugger, but it did make me wonder whether something
about the behavior of the Tomcat classloader against a previously unloaded
class, during shutdown might somehow lead to a null value here.



Or is that too fanciful?  Should I instead be figuring that the line number
is off because of an if statement extending over several lines, and that
either filename or refCounts must be null? The code doesn’t make that look
too likely, either, though,



Does anyone have any advice about tracking this down or mitigating it? Also
wondering whether this issue is related to occasional “missing fnm file”
errors we’ve seen when restarting Tomcat on this indexing server. That
error means I have to go in and make the index coherent again, generally by
aligning it with one of the slaves. I can see how a failure to delete files
might have that effect.



Thanks,



-- Bryan

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message