[jira] [Updated] (SOLR-6919) Log REST info before executing
[
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
I checked out {IndexWriter}} and {{InfoStream}} and think it might be somewhat
overengineered for this case.
How about we just create a child logger and use that? Then it will inherit the
default levels and settings from the SolrCore logger, or can be set separately
if desired. I've attached another patch with this if we think this is a good
path to go.
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
Fix For: Trunk, 5.1
Attachments: SOLR-6919.patch, SOLR-6919.patch, 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
[jira] [Updated] (SOLR-6919) Log REST info before executing
[ 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 Attaching a new patch that is built on top of the content that [~gchanan] already committed. 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 Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, 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
[jira] [Updated] (SOLR-6919) Log REST info before executing
[ 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 bq. should the slow query log also go to the request log? I can see an argument made for this, but I don't think it is necessary. bq. if you are generating this on top of what is already committed why does the test case look like a new file? I'm not sure, I must have made a mistake somewhere. Here's a new patch that looks correct w.r.t. the test case. 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 Fix For: Trunk, 5.1 Attachments: SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, SOLR-6919.patch, 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
[jira] [Updated] (SOLR-6919) Log REST info before executing
[ https://issues.apache.org/jira/browse/SOLR-6919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gregory Chanan updated SOLR-6919: - Attachment: SOLR-6919.patch Slight change to the test case. Checks that what we are matching against doesn't contain the post-debug information (i.e. status, hits, QTime). 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, 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
[jira] [Updated] (SOLR-6919) Log REST info before executing
[
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
[jira] [Updated] (SOLR-6919) Log REST info before executing
[ 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 Patch based on trunk, but also applies cleanly to 5x and 4x 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 Priority: Minor Attachments: 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
