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
