Varun Thacker created SOLR-13288: ------------------------------------ Summary: 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
After SOLR-12753 messages are limited to 10240 chars. +1 to the 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{yyyy-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