SOLR-18042 Manage MDC Logging Context setup/teardown in a servlet filter.

[gus-asf]

https://issues.apache.org/jira/browse/SOLR-18042

[gus-asf]

Failed tests look unrelated, passed a local ./gradlew check, and pass locally with specified seed individually

[dsmiley]

The most trivial & light-weight way to do MDC is simply try-finally with the next action inside. It wouldn't show up on the stack, which I find appealing. A Filter is the other end of the spectrum, on the heaviest possible side of ways to accomplish the goal. Requires configuration in web.xml/Jetty, multiple methods on the stack, maybe lifecycle. MDC requires no servlet-y stuff either in any way (unlike pathExcludes that you recently reworked). IMO this isn't a good trade-off.

[dsmiley]

I appreciate the comment but I think it could be worded more directly to the point.
"NOTE: Remember Solr has a series of Servlet filters in advance doing miscellaneous things like MDC, excludePatterns, ..."
The above comment would be searchablel.

[gus-asf]

The most trivial & light-weight way to do MDC is simply try-finally with the next action inside. It wouldn't show up on the stack, which I find appealing. A Filter is the other end of the spectrum, on the heaviest possible side of ways to accomplish the goal. Requires configuration in web.xml/Jetty, multiple methods on the stack, maybe lifecycle. MDC requires no servlet-y stuff either in any way (unlike pathExcludes that you recently reworked). IMO this isn't a good trade-off.

On the other hand if we don't make it a filter we can't pull anything it wraps out into an independent filter, and it won't be re-usable if after converting SolrDispatchFilter to a servlet (as has been discussed elsewhere) the admin stuff gets split out... I think if we are going to peel layers off the onion we need to preserve the order of the layers (at least initially). If after we've remodeled the current onion we don't like the order or want to eliminate some layers that's a possible next step. Another thing to think about is that while long stack traces are somewhat annoying, where they terminate contains more information, and if the code for the class/method where they terminate is simple debugging is simpler. Th

The less stuff we have in SolrDispatchFilter the better

It is probably better named "SolrDumpsterFilter" since it containing our dispatch logic plus a billion other things that have nothing to do with dispatch (deciding where to send the request). I fantasize about the day where it's sole job is to inspect the request so that /solr/foo/admin gets forwarded (dispatched) to /solr/admin with parameter collection=foo or /solr/query?collection=foo or /solr/update?collection=foo... so that the three major paths of our application can have simplified dedicated code paths (admin tasks don't need scatter-gather, so it should never get considered, but maybe should go to a specific node with the admin role? Maybe in some situations that should be a re-direct instead of a subrequest?)

[gus-asf]

I filled out the tasks in SOLR-18040 to give a better picture of why MDC probably wants to be pulled out into a filter

[dsmiley]

I'll approve based on your passion on the project. It's a shame that future filters that have not yet been pulled out rely on this trivial filter being a filter for those to be filters. Sigh.

[dsmiley]

Hopefully not a future Filter for just one line.
I sympathize with your characterization of SolrDispatchFilter as a kitchen sink but a few lines for certain topics at the critical Solr entrypoint is understandable IMO.