You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "Mikhail Khludnev (Jira)" <ji...@apache.org> on 2021/11/15 20:20:00 UTC
[jira] [Comment Edited] (SOLR-15438) Refactor: Simplify SolrDispatchFilter close/destroy
[ https://issues.apache.org/jira/browse/SOLR-15438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17352038#comment-17352038 ]
Mikhail Khludnev edited comment on SOLR-15438 at 11/15/21, 8:19 PM:
--------------------------------------------------------------------
[~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.
was (Author: dsmiley):
[~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
> Reporter: David Smiley
> Assignee: David Smiley
> Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org