lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edoardo Tosca <>
Subject DebugComponent behavour in a distributed environment
Date Fri, 01 Oct 2010 17:06:41 GMT
Hello everybody,
i have some doubts about the current behaviour of DebugComponent at
coordinator level in a sharded environment.
I'm actually using Solr 1.4
While trying to test our current system using debugQuery=on i have seen that
at coordinator level the timing element contains riduculous values if
comparedwith the QTime value sticked inside the header.
It basically reports only a subset of the time spent in executing the
distributed query and sincerely i think that it doesn't make so much sense.

After a quick debugging session i've discovered that the timing is
calcultated only on the last request executed by the coordinator to every
single node.
The request is the one that contains only specific docIds and therefore the
response time is usually fast.
Digging inside the code i've seen that the method called modifyRequest takes
care of setting debugQuery=false during the first request from the
coordionator to every node.

The question is:
is there a specific reason why modifyRequest "turns off" debugQuery?

I have started changing the code of this component.
I've changed code of modifyRequest so that now it never disables the debug.
Then i've sorted out how to retrieve timing values (divided per phase and
component) for each node. Every group of information is identifiedy by the
shard name.
I've setted these information inside the standard timing element.

I don't know if these information can be usuful to someone else, in case i
can provide a patch,
but most important i would like to be sure that changing modifyRequest does
not affect the search (it shouldn't but i really appreciate a confirmation )

Thank you,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message