[jira] [Resolved] (SOLR-18045) Manage top level SolrReqeustInfo in a filter?

["Gus Heck (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-18045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gus Heck resolved SOLR-18045.
-----------------------------
    Resolution: Won't Fix

I added a call to reset() at the end of EssentialSolrRequestFilter and removed it from HttpSolrCall, further renovation relating to SolrRequestInfo is too complex to be a subtask on 18040 in my opinion, so I'm marking this as wontfix

> Manage top level SolrReqeustInfo in a filter?
> ---------------------------------------------
>
>                 Key: SOLR-18045
>                 URL: https://issues.apache.org/jira/browse/SOLR-18045
>             Project: Solr
>          Issue Type: Sub-task
>          Components: Server
>            Reporter: Gus Heck
>            Priority: Minor
>
> SolrRequestInfo (SRI) is a complex beast with a stack of SolrRequestInfo instances, but generally there should be at least one available on each request. This currently seems to happen in HttpSolrCall but I wonder if it can't happen earlier. There are a few codepaths that don't seem to generate an SRI (i.e. 
> It's unclear if the instantiation of an initial SolrRequest info in a servlet filter makes sense, but the notion of finally block with SolrRequestInfo.reset() in it wrapping everything is attractive. 
> Another Possibility is to just add the call to reset() to the filter in SOLR-18043 and maybe think of that filter as "request Globals" management?
> What to do here is less clear, but this ticket is the place for ideas regarding the interaction of the lifecycle of SolrRequestInfo with our filters.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org