[jira] [Commented] (SOLR-13288) Async logging max length should only apply to the message
[ https://issues.apache.org/jira/browse/SOLR-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783587#comment-16783587 ] Erick Erickson commented on SOLR-13288: --- [~varunthacker] Is this theoretical or practical? 10K characters is enough to get the hits/status/QTime for the vast majority of cases. We've seen some very long queries where the 10K limit would truncate the end bits, and I suppose that if some of the update options were turned on where we dumped 1,000 IDs that would miss too. Hmmm, one other thing that just came to mind: What about stack traces? > Async logging max length should only apply to the message > - > > Key: SOLR-13288 > URL: https://issues.apache.org/jira/browse/SOLR-13288 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Major > > After SOLR-12753 messages are limited to 10240 chars. +1 for having a limit, > we even hit this issue internally recently. > > Sample log line > {code:java} > 2019-03-03 19:04:51.293 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingstarted_shard2_replica_n4] webapp=/solr path=/select > params={q=*:*&_=1551639889792} hits=0 status=0 QTime=206 } {code} > The way it's implemented currently though it picks the first 10240 chars from > the start. So let's say it was reduced to 10 the log line will look like > {code:java} > 2019-03-03{code} > If we wrap the {{maxLen}} around the message part then we ensure some parts > are always captured. So with this pattern > {code:java} > %d{-MM-dd HH:mm:ss.SSS} %-5p (%t) [%X{collection} %X{shard} %X{replica} > %X{core}] %c{1.} %maxLen{%m %notEmpty{=>%ex{short}}}{10}} %n{code} > the message will now look like > {code:java} > 2019-03-03 19:07:24.901 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingst} {code} > This is still not perfect as ideally we'd want to capture the > hits/status/QTime part even if the message get's shortened. I'm not sure if > the log4j2 Pattern Layout syntax support it? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13288) Async logging max length should only apply to the message
[ https://issues.apache.org/jira/browse/SOLR-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16783563#comment-16783563 ] John Gallagher commented on SOLR-13288: --- would be nice to put hits/status/QTime in MDC if possible, just like collection/shard/replica/core, that way the standard patternlayout can be used to only truncate the message portion, and to rearrange those to the front as desired by a customer. > Async logging max length should only apply to the message > - > > Key: SOLR-13288 > URL: https://issues.apache.org/jira/browse/SOLR-13288 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Major > > After SOLR-12753 messages are limited to 10240 chars. +1 for having a limit, > we even hit this issue internally recently. > > Sample log line > {code:java} > 2019-03-03 19:04:51.293 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingstarted_shard2_replica_n4] webapp=/solr path=/select > params={q=*:*&_=1551639889792} hits=0 status=0 QTime=206 } {code} > The way it's implemented currently though it picks the first 10240 chars from > the start. So let's say it was reduced to 10 the log line will look like > {code:java} > 2019-03-03{code} > If we wrap the {{maxLen}} around the message part then we ensure some parts > are always captured. So with this pattern > {code:java} > %d{-MM-dd HH:mm:ss.SSS} %-5p (%t) [%X{collection} %X{shard} %X{replica} > %X{core}] %c{1.} %maxLen{%m %notEmpty{=>%ex{short}}}{10}} %n{code} > the message will now look like > {code:java} > 2019-03-03 19:07:24.901 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingst} {code} > This is still not perfect as ideally we'd want to capture the > hits/status/QTime part even if the message get's shortened. I'm not sure if > the log4j2 Pattern Layout syntax support it? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13288) Async logging max length should only apply to the message
[ https://issues.apache.org/jira/browse/SOLR-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16782928#comment-16782928 ] Erick Erickson commented on SOLR-13288: --- Go for it. The 10240 limit was put naively in place to keep from OOMing on very long messages that came about very quickly, any refinement welcome. > Async logging max length should only apply to the message > - > > Key: SOLR-13288 > URL: https://issues.apache.org/jira/browse/SOLR-13288 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Varun Thacker >Assignee: Varun Thacker >Priority: Major > > After SOLR-12753 messages are limited to 10240 chars. +1 for having a limit, > we even hit this issue internally recently. > > Sample log line > {code:java} > 2019-03-03 19:04:51.293 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingstarted_shard2_replica_n4] webapp=/solr path=/select > params={q=*:*&_=1551639889792} hits=0 status=0 QTime=206 } {code} > The way it's implemented currently though it picks the first 10240 chars from > the start. So let's say it was reduced to 10 the log line will look like > {code:java} > 2019-03-03{code} > If we wrap the {{maxLen}} around the message part then we ensure some parts > are always captured. So with this pattern > {code:java} > %d{-MM-dd HH:mm:ss.SSS} %-5p (%t) [%X{collection} %X{shard} %X{replica} > %X{core}] %c{1.} %maxLen{%m %notEmpty{=>%ex{short}}}{10}} %n{code} > the message will now look like > {code:java} > 2019-03-03 19:07:24.901 INFO (qtp776700275-57) [c:gettingstarted s:shard2 > r:core_node7 x:gettingstarted_shard2_replica_n4] o.a.s.c.S.Request > [gettingst} {code} > This is still not perfect as ideally we'd want to capture the > hits/status/QTime part even if the message get's shortened. I'm not sure if > the log4j2 Pattern Layout syntax support it? -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org