I think I'd prefer to have that single core instance and a slower first request instead of doing extra initialization work and then letting extra instances linger... seems cleaner.
Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch ----- Original Message ---- > From: Chris Hostetter <[EMAIL PROTECTED]> > To: Solr Dev <[email protected]> > Sent: Tuesday, May 27, 2008 6:27:18 PM > Subject: Add SolrCore.getSolrCore() to SolrServlet.doGet to work arround > Resin bug? > > > 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
