[
https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Drob updated SOLR-6919:
----------------------------
Attachment: SOLR-6919.patch
An example of the logging:
{noformat}
2997 T13 C0 oasc.SolrCore.execute DEBUG [collection1] webapp=null path=null
params={q=*:*&wt=xml}
3037 T13 C0 oasc.SolrCore.execute [collection1] webapp=null path=null
params={q=*:*&wt=xml} hits=0 status=0 QTime=41
{noformat}
I pulled this out of {{tests-report.txt}} so the format might not be exactly
the same as on a production system, but the content is mostly there. The first
line is the line I added, which happens before the query exceutes. The second
line already exists, and is logged after processing completes. These two lines
are very similar.
One advantage of logging this local to Solr is that it will help correlate
events when troubleshooting. If several requests come in near the same time, it
may not be clear which one caused isseus if they are all elsewhere (i.e. in
container logs).
I've added a simple test to ensure that the logging occurs, but it might be a
good idea to test with a more complicated query set to see if you get better
results.
> Log REST info before executing
> ------------------------------
>
> Key: SOLR-6919
> URL: https://issues.apache.org/jira/browse/SOLR-6919
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: Mike Drob
> Assignee: Gregory Chanan
> Priority: Minor
> Attachments: SOLR-6919.patch, SOLR-6919.patch
>
>
> We should log request info (path, parameters, etc...) before attempting to
> execute a query. This is helpful in cases where we get a bad query that
> causes OOM or something else catastrophic, and are doing post-event triage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
