[jira] [Commented] (LOG4J2-1137) Allow events to be buffered until something triggers and causes them to be logged.

["Robert F (JIRA)" <ji...@apache.org>]

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

Robert F commented on LOG4J2-1137:
----------------------------------

We're looking for the same functionality.  

And while I'm new to Log4j2, I would like to convey my preferences for the RingBufferAppender

a) It should contain the formatted text; i.e. params will change after they are logged.  _(NOTE: It is up to developers to avoid performance issues.)_

b) Filters control what is logged to the RingBuffer.  _(This also allows performance entries to be filtered out.)_

c) I'm not interested in a second filter to control what gets dumped from the RingBuffer (but others may desire this); i.e. it's easy for me to post-filter the dump file.

d) I'm fine with a dump of the entire buffer (up to the current timestamp).  

_However, I could see later enhancements to specify the number of pre/post-events or start/end timestamps (where the end could be in the future).  I assume these options would be controlled in the config file.  And hope they support fine grain control where I specify the defaults, but can then override the defaults when a particular problem area arises in a given part of the code; e.g. a regexp match could override the defaults._

e) The config should specify the dump file; e.g. rolling dump file.  I do not want the dump mixed with the standard log files.

f) The dump trigger mechanism can be from both code (e.g. LOG.dump()) and the config.  This allows the developer to specify what issues they wish to dump, while the config allows them to be shutoff or for missing dumps to be added.

   if (condition) {
      LOG.fatal(msg);
      LOG.dump();
   }

Best regards.

> Allow events to be buffered until something triggers and causes them to be logged.
> ----------------------------------------------------------------------------------
>
>                 Key: LOG4J2-1137
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-1137
>             Project: Log4j 2
>          Issue Type: New Feature
>          Components: Core
>    Affects Versions: 2.4
>            Reporter: Ralph Goers
>            Priority: Major
>
> In many cases logging is filtered in production to reduce the overhead of logging. Unfortunately, this means that when an error occurs there may not be enough logging information available to diagnose the problem. On the other hand, if filtering is minimized then the amount of data being logged can be overwhelming.
> This enhancement would allow log events to be written to a buffer and not processed any further until a triggering event occurs. Once that trigger occurs all the events in the buffer would be logged in sequence and pass through the normal filtering process.  Some log events that are deemed "special" would need to be allowed to bypass the buffer and immediately be processed.
> One way to accomplish this would be to add a new LogBuffer component to the configuration. If configured, the ReliabilityStrategies could be modified to work with the LogBuffer or a BufferingReliabilityWrapperStrategy could be created to wrap the existing strategies.
> Note - no code has been written for this yet. I'd want to figure out what the configuration might look like before starting.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)