[
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15559757#comment-15559757
]
Remko Popma commented on LOG4J2-1630:
-------------------------------------
Sorry I'm a bit late with my reply...
Regarding your first comment:
I edited my previous comment to remove the TimeMachineBuffer references.
You are right, I did not mention concurrency yet. I wanted to focus on
functional requirements first and for the Unit of Work use case I need to do
more analysis with concurrency in mind.
I hope my edits clarified the Unit of Work use case. It is not the case that
events are going to be tossed if the unit of work is "committed" and logged if
it is "rolled back". It is the opposite. If a unit of work is discarded or
"rolled back", the associated events are removed from the buffer. Commit or
Flush means send the buffer contents to the target appenders so the events get
logged.
When is Unit of Work useful? I work with systems that process millions of
messages per day. The system only reacts to a fraction of these events. During
processing, the system often repeats the same calculations. These get quite
involved and there is detailed logging in these components. We want to log
details from these calculations only when the system took action.
An ad hoc way to deal with this is to let the application gather log messages
somewhere outside the logging framework, and when the application knows it took
action, then send them to the logging framework, otherwise discard them.
The fact that this ad hoc solution bypasses the logging framework suggests to
me that the logging framework is missing an abstraction. Also, if some of the
logging takes place in 3rd party libraries even this option is not available.
----
Regarding your second comment:
At first I thought implementing EventBuffer as a Filter is an interesting idea.
Filters can be applied anywhere so this seems very powerful.
However, thinking about this further I got confused. Especially example
scenarios (a) and (b) threw me: Loggers _produce_ log events, they don't
_consume_ them. What does it mean for an EventBuffer to intercept and buffer
events before they reach the Logger? If it sits before the Logger then LogEvent
objects have not been created yet. What is EventBuffer intercepting and how can
it release these things to the Loggers?
>From a design perspective, a Filter's responsibility is to _judge_ whether a
>log event or its constituents should be ACCEPTed, DENied or we don't care
>(NEUTRAL). By design, Filters don't have an AppenderRef or another way to send
>events to a receiver. Changing this, and changing the role/responsibility of a
>central concept like Filter is very impactful. I am not convinced this is a
>good idea.
At the end of the day, log events are consumed by Appenders. I think we all
agree that EventBuffer needs sit somewhere before the Appenders. I was thinking
of EventBuffer as simply an intermediate stage in the appenders pipeline like
AsyncAppender or RoutingAppender. What would be the benefit of moving it
further upstream and making it sit before the Loggers? Is there a use case that
I am missing? I don't understand what are you trying to achieve with this.
> Unit of Work Logging
> --------------------
>
> Key: LOG4J2-1630
> URL: https://issues.apache.org/jira/browse/LOG4J2-1630
> Project: Log4j 2
> Issue Type: Story
> Components: API, Core, Filters
> Affects Versions: 2.7
> Reporter: Remko Popma
> Fix For: 2.8
>
>
> h3. Intent
> Provide a way to filter log events, where the decision on whether to discard
> the message or actually log them cannot be made until after the application
> has already logged the message.
> h3. Motivation
> In many systems, particularly event processing applications, log files
> contain a lot of repetitive log messages. Suppose an application needs to do
> some calculation to decide whether or not to react to some event, and a lot
> of detail is logged during this calculation. Imagine that 99% of the time,
> the application decides to take no action. Once the application arrived at
> that conclusion it would be nice if we could go back and undo all the
> detailed logging and print a summary instead. When the application _does_
> decide to take some action, however, we _do_ want the detailed log messages.
> A Unit of Work for logging would allow us to group a set of log messages and
> either discard them or log them together. (Inspired by Martin Fowler's [Unit
> of Work|http://martinfowler.com/eaaCatalog/unitOfWork.html] pattern.)
> This should result in log files where a lot of the "uninteresting" logging is
> filtered out, significantly reducing the amount of data logged.
> Some applications do this in an ad hoc manner, for example by passing a
> Collection to its components, where these components can add log message
> strings to this Collection. When the discard/retain decision is made, the
> application then either clears the Collection or logs the contents of the
> Collection. This works, but having to pass the Collection down the component
> tree is clunky and the result often omits details like logger name, timestamp
> and other details that come for free with normal logging. Log4j can provide a
> reusable and less intrusive way to accomplish this.
> h3. How it works
> There would need to be some API for the application to mark the _start_ of
> the unit of work, and some API to signal whether the log messages that are
> part of that unit of work need to be _discarded_ or _logged_ (retained).
> Not all logging that occurs after a unit of work was started is part of that
> unit of work. The application may want some messages to be logged regardless
> of whether the unit of work was discarded or not. There needs to be a
> flexible way (or multiple ways) to include or exclude logging statements from
> the unit of work.
> The application may also designate multiple units of work, which may be
> sequential, nested or partially overlapping. Each unit of work may define its
> own rules for which log messages are considered included in or excluded from
> the unit of work.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
