[
https://issues.apache.org/jira/browse/SOLR-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Varun Thacker updated SOLR-13288:
---------------------------------
Description:
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{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?
was:
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?
> 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{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
