[
https://issues.apache.org/jira/browse/LOG4J2-2538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16754879#comment-16754879
]
Deshui Yu commented on LOG4J2-2538:
-----------------------------------
This issue has almost the same idea to LOG4J2-1137
> A memory appender that can be triggered to dump in-memory logging messages to
> file
> ----------------------------------------------------------------------------------
>
> Key: LOG4J2-2538
> URL: https://issues.apache.org/jira/browse/LOG4J2-2538
> Project: Log4j 2
> Issue Type: New Feature
> Components: Appenders
> Affects Versions: 2.11.1
> Reporter: Deshui Yu
> Priority: Major
>
> We have a problem when debugging an online production system. Our
> production system manages and distributes data across multiple worker
> machines. There's a bug that can cause data unbalanced placement or even
> unavailable under heavy work load. In this scenario, DEBUG level log will
> help us a lot to diagnose the issue. However, we cannot always set logger's
> level to DEBUG because that will store too many logs on disk and slow down
> the production service, especially the bug just occurs occasionally.
> I think we can add a new type of memory appender in Log4j. This appender
> will store log entries in a memory queue first, with a configurable maximum
> queue size and a policy (like FIFO) to roll out stale log entry once the
> queue is full. If any problem occurs, like some types of exception we're
> interest is thrown, user can trigger the dump of this appender to flush in
> memory logs into file for future diagnostic use. So it can only record
> 'useful' DEBUG logs and related context in disk, avoid wasting disk space and
> slowing down production service.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
