Over a year ago, Ryan noticed that Resin wasn't correctly loading the
SolrDispatchFilter prior to the SolrServlet in violation of the Servlet
Spec...
https://issues.apache.org/jira/browse/SOLR-166?focusedCommentId=12474310#action_12474310
...at the time, the only downside of this was a weird error which was
easily dealt with usingsome more robust error handling. However,
with the addition of the multicore code to SolrDispatchFilter, the result
now is that...
1) SolrServlet.init() calls SolrCore.getSolrCore()
1.1) SolrCore.getSolrCore() sees no singleton, so it
constructs a new instance and sets the singleton
1.2) SolrServlet stores the result in a member variable "core"
2) SolrDispatchFilter.init calls "new SolrCore(...)"
2.1) the constructor for SolrCore sets the singleton
(per previous discussion about how two best support "legacy" uses
of the singleton in a multicore world: it's always the "newest"
core)
3) SolrServlet.doGet uses it's private core, which is now differnet then
what SolrDispatchFilter is using.
Meanwhile, the legacy SolrUpdateServlet winds up getting the "current"
singleton for every request.
...it seems like a simple fix to try and make things more correct
(regardless of what order things are loaded in) would be to either...
a) remove the getSolrCore() call in SolrServlet.init() and replace the
"core" member variable with a new call to getSolrCore() at the start of
doGet().
OR
b) Leave the getSolrCore() call in SolrServlet.init(), but still replace
the "core" member variable with a new call to getSolrCore() at the start
of doGet().
Option (a) would insure that only one core ever exists, regardless of
which order the various classes are initalied in, as long as the Filter
was initialized before the first request to SolrServlet -- but that first
request might be slower for legacy users of SolrServlet. Option (b) would
garuntee that at least one core was initialzed before the first request so
it would be just as fast for legacy users of SolrServlet, at the expensive
of initializing (and then ignoring) an extra SolrCore.
Either appraoch would ensure that SolrServlet was at least consistent with
SolrUpdateServlet (and SolrDispatchFilter) in always using the "current"
singleton core.
thoughts?
-Hoss
