[ 
https://issues.apache.org/jira/browse/SOLR-6039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-6039:
---------------------------

    Attachment: SOLR-6039.patch

bq. This patch adds the timing info in all phases. The times responded by 
shards are still being added

Yeah ... i think for now it makes sense to just "fix" the bug relating ot 
wether the info comes back - but leave the definition the same as it's been and 
leave the question for wether the timing info should be "merged" differnetly 
for another issue (i can see different advantages to both sum vs max)

I didnt' fully understand the changes you made when skimming your patch -- but 
i did understand your test, and it looks good & fairly ccomprehensive and fills 
me with confidence that the fix is correct.  One thing i thing i noticed was 
still missing though is some testing of picking multiple options (ie: 
"debug=query&debug=timing") so i've added a randomized testing method that 
accounts for that case 9among other things)




> debug=track causes debug=query info to be suprsedd when no results found
> ------------------------------------------------------------------------
>
>                 Key: SOLR-6039
>                 URL: https://issues.apache.org/jira/browse/SOLR-6039
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.7
>            Reporter: Hoss Man
>         Attachments: SOLR-6039.patch, SOLR-6039.patch, SOLR-6039.patch
>
>
> Shamik Bandopadhyay noted on the mailing list that debugQuery=true wasn't 
> returning info about how the query was being parsed in SolrCloud.
> Steps to reproduce...
> * startup a simple 2 shard solr cluster using the example configs
> * Load this URL:
> ** http://localhost:8983/solr/select?q=Foo&debug=query
> ** note that the debug=query causes a debug block including "parsedquery" 
> showing "title:foo"
> * Load either of these URLs:
> ** http://localhost:8983/solr/select?q=Foo&debug=query&debug=track
> ** http://localhost:8983/solr/select?q=Foo&debugQuery=true (legacy short hand 
> option for enabling all debug options)
> ** Note that the debug block exists, but *only* includes the distributed 
> "track" options - the query parsing debugging info is not available
> * index the sample data (java -jar post.jar *.xml)
> * Load either of these URLs:
> ** http://localhost:8983/solr/select?q=Solr&debugQuery=true&fl=id
> ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&fl=id
> ** Note that now we have at least one matching doc, and the parsedquery info 
> is included in the debug block along with the tracking info
> * Load either of these URLs:
> ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0
> ** http://localhost:8983/solr/select?q=Solr&debug=query&debug=track&rows=0
> ** Note: even though we have a matching doc, since rows=0 prevents it from 
> being returned, the parsedquery debug info again no longer works - just the 
> track debug info
> ----
> The work around, for people who want don't care about the newer "debug 
> tracking" and what the same debug information as pre-4.7, is to enumerate the 
> debug options (ie: {{debug=query&debug=timing&debug=results}}) instead of 
> relying on the shorthand: {{debugQuery=true}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to