gus-asf commented on PR #3985: URL: https://github.com/apache/solr/pull/3985#issuecomment-3694902463
> 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 and 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?) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
