logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remko Popma (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (LOG4J2-1137) Allow events to be buffered until something triggers and causes them to be logged.
Date Mon, 28 Sep 2015 12:50:04 GMT

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

Remko Popma edited comment on LOG4J2-1137 at 9/28/15 12:49 PM:
---------------------------------------------------------------

So, the idea is to have a small ring buffer with the most recent LogEvent objects. Once the
ring buffer is full, new log events replace the oldest log events in the ring buffer until
a new log event contains some trigger that causes the full contents of the ring buffer to
be drained to the target appender(s).

What happens with new log events that arrive after a triggering event? Keep draining to the
target appenders? (If so, keep draining only for some limited number of events, or until some
"untrigger" event, or forever?)

Since performance is a big part of the motivation for this idea, it would make sense to use
a non-blocking data structure similar to the RingBuffer used in the LMAX Disruptor. In fact,
I think the Disruptor library contains components to achieve this out of the box. Or does
this need to be synchronous? (Synchronous here would mean that the application thread delivering
the triggering event will block until the full content of the ring buffer has been processed
by all appenders.)


was (Author: remkop@yahoo.com):
So, the idea is to have a small ring buffer with the most recent LogEvent objects. Once the
ring buffer is full, new log events replace the oldest log events in the ring buffer until
a new log event contains some trigger that causes the full contents of the ring buffer to
be drained to the target appender(s).

What happens with new log events that arrive after a triggering event? Keep draining to the
target appenders? (If so, keep draining only for some limited number of events, or until some
"untrigger" event, or forever?)

Since performance is a big part of the motivation for this idea, it would make sense to use
a non-blocking data structure similar to the RingBuffer used in the LMAX Disruptor. In fact,
I think the Disruptor library contains components to achieve this out of the box. Or does
this need to be synchronous? (This would mean the application thread delivering the triggering
event will block until the full content of the ring buffer has been processed by all appenders.)

> 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
>
> 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
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org


Mime
View raw message