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.
