[
https://issues.apache.org/jira/browse/SOLR-12896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17351799#comment-17351799
]
David Smiley commented on SOLR-12896:
-------------------------------------
There is a [commit|75b183196798232aa6f2dcaaaab117f309119053] referencing this
JIRA issue that adds a SolrDispatchFilter.closeOnDestroy boolean with check for
this in JettySolrRunner.stop(). It appears the change was to have close be
called in a separate thread. Yet a subsequent commit a few days later to
JettySolrRunner.stop commented this out yet kept closeOnDestroy. I think the
pertinent lines of code can be reverted to thus have what existed previously,
which was simpler?
BTW [~markrmil...@gmail.com] I'm looking very closely at the
SolrDispatchFilter.close/destroy process to ensure I understand it thoroughly.
The background is that I neglected to notice that the reference to
CoreContainer gets nulled out (on close) when I recently made changes in this
class, and I started to wonder why we even bother nulling it out at all (not a
change you did BTW), and then I find myself trying to simplify close/destory.
It appears cores==null is trying to signify equivalency with cores.isShutdown()
maybe before there even was such a method on CoreContainer.
> Introduce more checks for shutdown and closed to improve clean close and
> shutdown.
> ----------------------------------------------------------------------------------
>
> Key: SOLR-12896
> URL: https://issues.apache.org/jira/browse/SOLR-12896
> Project: Solr
> Issue Type: Sub-task
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Major
> Fix For: 7.6
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
