Hi Folks, I would like to improve the structure of our code to enable easier maintenance, better readability, better extensibility and better customizability for power users. I believe one step in the right direction is to embrace the use of multiple ServletFilters such that elements of setup and teardown for request processing are segregated into distinct, focused classes. I had talked with many individuals about it and espoused this opinion on the list several times with no significant opposition and some encouragement so, with some time to spare over the holidays I filed a ticket, created tasks. Feedback on review indicated that there was a feeling this needed (further, formal) discussion on the list, so here it is.
The ticket I filed is https://issues.apache.org/jira/browse/SOLR-18040 - Overall this change should be transparent to most users - I expect this change to make it MUCH easier to identify the various independent "housekeeping" (non-search) tasks required to handle requests such as: - Excluding some paths to enable UI files without auth - Setting some request attributes, - Rate Limiting - Initialization/completion of tracing - Initialization/completion of auditing - Authentication/Authorization (later task to handle those separately) - Post request cleanup of SolrRequestInfo, fully consuming requests, deleting multi-part request temp files, etc. - Power users seeking to optimize solr, or with special needs wrt auth/audit/tracing/rate-limiting would be able to replace or eliminate these aspects. - Addition of new request handling features can easily be slotted in between existing features (either by folks contributing to the project, or power users customizing Solr). - If well named, the list of filters in web.xml will serve as high level self documenting code, revealing the types of and order of the initial request processing. The only opposition I have ever heard previously is the relatively vague notion that someday we might want to get rid of Jetty entirely. Such a change has been mentioned ever since we stopped packaging Solr as a .war file. And while, in theory, it could provide optimization of request processing, it strikes me both as something nobody is prepared to do any time soon, and as something that runs a huge risk of re-inventing a lot of wheels for little gain. On the other hand, leaning into Servlet filters can be done now, quickly and if we ever "dump" jetty it will directly translate to a set of request decorators we will need anyway. I expected that the coding effort for this would be just a few days and so far that has not been contradicted yet, though the need to wait for review on every single step, and the fact that Crave has not been picking up PR build requests for multiple hours has significantly extended the wall clock. I'm having some thoughts on how we can mitigate this tension between small changes and molasses-like progression, however that's a separate discussion. If you have thoughts for or against this direction please speak up now. -Gus -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
