A searcher that has not yet been registered is not tracked anywhere and may not be closed if the core is closed.
Bulk close for 3.1.0 release
This doesn't really represent that serious of an issue - but it's nice to get it out of the way so that it doesn't mask more serious ones.
With this patch, all of the remaining searcher leaks look to be taken care of.
Basically, the idea is to wait for the search executor to finish before closing the main searcher.
Here's the patch:
New comments in the code explain a little more:
+ // Since we waited for the searcherExecutor to shut down,
+ // there should be no more searchers warming in the background
+ // that we need to take care of.
+ // For the case that a searcher was registered *before* warming
+ // then the searchExecutor will throw an exception when getSearcher()
+ // tries to use it, and the exception handling code should close it.
Is the searcher registered pre or post warming?
I've been seeing some strange errors in the tests, and I noticed that it was all very short tests that didn't do any queries that were the problem.
So the core starts up, asynchronously a searcher is created + warmed, and then the core is shut down before that searcher is even registered (or the core has a reference to it to close it).
This doesn't seem particularly easy to solve, unless you completely synchronize the reader.reopen() + new searcher creation.