[
https://issues.apache.org/jira/browse/SOLR-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352038#comment-17352038
]
David Smiley commented on SOLR-15438:
-------------------------------------
[~mkhl] I've read parts of related JIRAs, and in particular your realization
here:
https://issues.apache.org/jira/browse/SOLR-9867?focusedCommentId=15990057&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15990057
where you claim that a Filter.doFilter can be called before Filter.init is
called! That's a shocker. Can you suggest how I could reproduce this? I can
add an assert easily enough but I wonder what test you recommend to reproduce
it.
> Refactor: Simplify SolrDispatchFilter close/destroy
> ---------------------------------------------------
>
> Key: SOLR-15438
> URL: https://issues.apache.org/jira/browse/SOLR-15438
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
>
> SolrDispatchFilter's close process is more convoluted than it needs to be.
> There is conditionality via a boolean closeOnDestory that JettySolrRunner
> uses, yet it seems it doesn't really need this logic. JSR could instead call
> Jetty FilterHolder stop() method which tracks lifecycle to know if it hasn't
> been called, and it can skip needless null checks. Also SDF's reference to
> CoreContainer needn't be null'ed out, which makes some logic simpler above
> that needn't guard against null. The HttpClient needn't be null'ed either.
> We don't need a reference to SolrMetricManager; it can be gotten from
> CoreContainer easily.
--
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
