lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe (JIRA) <j...@apache.org>
Subject [jira] [Updated] (SOLR-6039) debug=track causes debug=query info to be suprsedd when no results found
Date Fri, 02 May 2014 01:12:16 GMT

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

Tomás Fernández Löbbe updated SOLR-6039:
----------------------------------------

    Attachment: SOLR-6039.patch

I'm looking into this issue. This patch would fix the problem described in the users list
with the query explain, but not yet the with the timing. 
I kind of see where the timing issue is too, but I'm wondering if this is expected. Seems
like the timing info should be merged in DebugComponent.finishStage(...), but as it is now,
it would only consider the time spent in the phases with GET_DEBUG purpose. This purpose is
only included in in the GET_FIELDS phase, we would not be considering time in parts of the
request?
In addition, once it gets the timing information from the shards it adds it. I think it would
be better if it get the max value instead? after all, the time in each phase will be the time
the slowest shard took, right?

> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message