I have had this exact same use case and we ended up just setting a header value, then in a Servlet Filter we read the header value and set the MDC property within the filter. By reading the header value it didn’t complain about reading the request before making it to the SolrDispatchFilter. We used the Jetty web defaults to jam this functionality at the beginning of the servlet processing chain without having to crack open the war.
-Steve On Apr 7, 2014, at 8:01 PM, Michael Sokolov <msoko...@safaribooksonline.com> wrote: > Yes, I see. SolrDispatchFilter is - not really written with extensibility > in mind. > > -Mike > > On 4/7/14 3:50 PM, Gregg Donovan wrote: >> Michael, >> >> Thanks! Unfortunately, as we use POSTs, that approach would trigger the >> getParameterIncompatibilityException call due to the Enumeration of >> getParameterNames before SolrDispatchFilter has a chance to access the >> InputStream. >> >> I opened https://issues.apache.org/jira/browse/SOLR-5969 to discuss further >> and attached our current patch. >> >> >> On Mon, Apr 7, 2014 at 2:02 PM, Michael Sokolov < >> msoko...@safaribooksonline.com> wrote: >> >>> I had to grapple with something like this problem when I wrote Lux's >>> app-server. I extended SolrDispatchFilter and handle parameter swizzling >>> to keep everything nicey-nicey for Solr while being able to play games with >>> parameters of my own. Perhaps this will give you some ideas: >>> >>> https://github.com/msokolov/lux/blob/master/src/main/java/ >>> lux/solr/LuxDispatchFilter.java >>> >>> It's definitely hackish, but seems to get the job done - for me - it's not >>> a reusable component, but might serve as an illustration of one way to >>> handle the problem >>> >>> -Mike >>> >>> >>> On 04/07/2014 12:23 PM, Gregg Donovan wrote: >>> >>>> That was my first attempt, but it's much trickier than I anticipated. >>>> >>>> A filter that calls HttpServletRequest#getParameter() before >>>> SolrDispatchFilter will trigger an exception -- see >>>> getParameterIncompatibilityException [1] -- if the request is a POST. It >>>> seems that Solr depends on the configured per-core SolrRequestParser to >>>> properly parse the request parameters. A servlet filter that came before >>>> SolrDispatchFilter would need to fetch the correct SolrRequestParser for >>>> the requested core, parse the request, and reset the InputStream before >>>> pulling the data into the MDC. It also duplicates the work of request >>>> parsing. It's especially tricky if you want to remove the tracing >>>> parameters from the SolrParams and just have them in the MDC to avoid them >>>> being logged twice. >>>> >>>> >>>> [1] >>>> https://github.com/apache/lucene-solr/blob/trunk/solr/ >>>> core/src/java/org/apache/solr/servlet/SolrRequestParsers.java#L621:L628 >>>> >>>> >>>> On Sun, Apr 6, 2014 at 2:20 PM, Alexandre Rafalovitch <arafa...@gmail.com >>>>> wrote: >>>> On the second thought, >>>>> If you are already managing to pass the value using the request >>>>> parameters, what stops you from just having a servlet filter looking >>>>> for that parameter and assigning it directly to the MDC context? >>>>> >>>>> Regards, >>>>> Alex. >>>>> Personal website: http://www.outerthoughts.com/ >>>>> Current project: http://www.solr-start.com/ - Accelerating your Solr >>>>> proficiency >>>>> >>>>> >>>>> On Sat, Apr 5, 2014 at 7:45 AM, Alexandre Rafalovitch >>>>> <arafa...@gmail.com> wrote: >>>>> >>>>>> I like the idea. No comments about implementation, leave it to others. >>>>>> >>>>>> But if it is done, maybe somebody very familiar with logging can also >>>>>> review Solr's current logging config. I suspect it is not optimized >>>>>> for troubleshooting at this point. >>>>>> >>>>>> Regards, >>>>>> Alex. >>>>>> Personal website: http://www.outerthoughts.com/ >>>>>> Current project: http://www.solr-start.com/ - Accelerating your Solr >>>>>> >>>>> proficiency >>>>> >>>>>> On Sat, Apr 5, 2014 at 3:16 AM, Gregg Donovan <gregg...@gmail.com> >>>>>> >>>>> wrote: >>>>> >>>>>> We have some metadata -- e.g. a request UUID -- that we log to every log >>>>>>> line using Log4J's MDC [1]. The UUID logging allows us to connect any >>>>>>> >>>>>> log >>>>>> lines we have for a given request across servers. Sort of like Zipkin >>>>>> [2]. >>>>>> Currently we're using EmbeddedSolrServer without sharding, so adding the >>>>>>> UUID is fairly simple, since everything is in one process and one >>>>>>> >>>>>> thread. >>>>>> But, we're testing a sharded HTTP implementation and running into some >>>>>>> difficulties getting this data passed around in a way that lets us >>>>>>> trace >>>>>>> all log lines generated by a request to its UUID. >>>>>>> >>>>>>> >
