[SOLR-597] Need to remove SolrCore "caching" from SolrServlet

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.3
• Fix Version/s: 1.3
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 12/Jun/08 17:53
• Updated: 10/May/13 10:41
• Resolved: 12/Jun/08 20:58

Description

As discussed in this thread...

http://www.nabble.com/Add-SolrCore.getSolrCore%28%29-to-SolrServlet.doGet-to-work-arround-Resin-bug--to17501487.html#a17515374

SolrServlet currently calls SolrCore.getSolrCore() during it's init method, and then caches that core for reuse on each requests.

Now that we have multicore support, and the decision was made that the singleton accessor should always return the more recently created core, this behavior is inconsistent with SolrUpdateServlet which calls SolrCore.getSolrCore() on each request.

One potential problem with this is that in a "mixed use" setup, where some requests are handled by the SolrDispatchFilter and some are handled by the SolrServlet you'll get insonstent results as cores are reloaded/renamed.

Another problem that has been observed "in the wild" is that since some versions of Resin do not correctly load Filter's before Servlets, the SolrServlet is constructing a core that only it ever sees before the DispatchFilter has a chance to construct the "normal" core.

The consensus solution is to make SolrServlet refetch the SolrCore singleton on each request – this means that heavily customized legacy setups that do not use the SolrDispatchFilter at all will not see initialization "lag" or errors until the first request. butthis seems acceptible given that SolrServlet is already deprecated - anyone using SolrServlet in a customized application who upgrades will want to start using the DispatchFilter anyway.