I agree with Otis and prefer the cleaner approach. By the way, I have filed a bug with Caucho for this particular resin bug:
http://bugs.caucho.com/view.php?id=2706 We have a support contract with them so this will be fixed in the next release. Bill On Tue, May 27, 2008 at 6:33 PM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: > 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 > >
