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. >>>>> >>>>> >
