[ 
https://issues.apache.org/jira/browse/LOG4J2-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241367#comment-15241367
 ] 

Ralph Goers commented on LOG4J2-1366:
-------------------------------------

I agree. I also don't know why you would want to increment the counter for 
events that are filtered. For example, if you are only logging info and above 
why would you want to increment the sequence on debug messages. This would 
create gaps and pretty much make it impossible for anyone to find the gaps 
where events were "dropped".

> Detecting async logger overflows using a sequence number
> --------------------------------------------------------
>
>                 Key: LOG4J2-1366
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1366
>             Project: Log4j 2
>          Issue Type: Wish
>          Components: Appenders
>    Affects Versions: 2.5
>            Reporter: Nicholas Wertzberger
>            Priority: Minor
>   Original Estimate: 2h
>  Remaining Estimate: 2h
>
> I'm trying to build log drop detection into our system. It's OK to lose 
> messages, and I'd rather lose messages that drop service, but it's NOT OK to 
> not know that log messages were dropped.
> While looking around, i see that log4j2 has this concept of a sequence number 
> in its PatternLayout. After browsing the source code, it seems that the event 
> has to make it all the way to the appender doing the pattern layout to get 
> the sequence id to increment.
> As a potential solution, I propose that this sequence id is moved to be a 
> static member of the AbstractLogger class, and increment on every call to 
> log.  This would allow me to detect dropped log messages by looking for gaps 
> in the sequence.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to