So to rephrase:
Solr will barf at unknown parameters, so we cannot currently send them in
band.
And the out of band dies not work due to post body handling complexity.
You are proposing effectively a dynamic set with common prefix to stop the
complaints. Plus the code to propagate those params.
Is that a good general description? I am just wondering if this can be
matched to some other real issues as well.
Regards,
Alex
On 07/04/2014 11:23 pm, "Gregg Donovan" <gregg...@gmail.com> 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.
> > >>
> >
>
