[
https://issues.apache.org/jira/browse/LOG4J2-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15557948#comment-15557948
]
Remko Popma commented on LOG4J2-1630:
-------------------------------------
I've been thinking about the differences and similarities between the Unit of
Work use case and the LOG4J2-1137 use case. Let me know if my understanding of
LOG4J2-1137 is wrong.
The LOG4J2-1137 feature still needs a name. What about "*TimeMachine*"? It
essentially gives you a way go back in time and write a preconfigured amount of
past log events. It is simpler than Unit of Work but gives the application less
control.
The Unit of Work idea lets an application postpone the decision whether to
discard a group of log events or not, similarly to rolling back a database
transaction spanning multiple inserts. It gives more fine-grained control but
the application needs to explicitly demarcate the start and end point, and
decide in code whether to roll back or not.
I think both ideas are useful. TimeMachine's ease of use makes it applicable to
a wide range of applications. UnitOfWork may be most suitable for event
processing systems that deal with high volumes of highly repetitive data.
More detailed comparison:
*Enqueueing Behaviour*
* Unit of Work: by default do *not* enqueue but send to underlying appenders,
*unless* a Unit of Work is in progress or the event starts a new Unit of Work.
* TimeMachine: by default *enqueue* the event, *unless* an
_immediateFlushFilter_ is configured that accepts the event.
*Buffer Full Behaviour*
If buffer is full when attempting to add a new event:
* Unit of Work: this should not happen, or is a sign the buffer size is
misconfigured. I'm thinking the best thing to do is to flush the buffer (write
all events to the appenders) and reset any units of work that were in progress.
* TimeMachine: buffer full is the normal state (buffer is usually small).
Discard the oldest event to make space, and add the new event to the buffer
(typical ring buffer).
*Flush Trigger*
What should trigger a flush? Likely candidates are log events, or an API call
of some kind. I am not in a rush to create additional API for this.
* Unit of Work: TBD, but likely fixed and controlled by the application - no
need to make this configurable. One option is to use a predefined
"UnitOfWork-Flush" Marker, the remaining challenge is how to obtain the name of
the unit of work since they can be nested.
* TimeMachine: TBD, but likely configurable. One option is to filter on log
event, like ERROR level ThresholdFilter.
*Rollback Behaviour*
* Unit of Work: remove all log events part of this unit of work from the
buffer. This may leave the buffer empty, unless the unit was nested in a larger
unit of work that is still in progress.
* TimeMachine: no equivalent
An example TimeMachine configuration could look like this:
{noformat}
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
<Appenders>
<Console name="console" target="SYSTEM_OUT"><PatternLayout pattern="%d [%t]
%p %c{36} - %m%n"/></Console>
<File name="file" fileName="app.log" ><PatternLayout pattern="%d [%t]
%p %c{1.} - %m%n"/></File>
<File name="errors" fileName="err.log" ><PatternLayout pattern="%d [%t]
%p %c{1.} - %m%n"/></File>
<TimeMachineBuffer name="timeMachine" size="128">
<ThresholdFilter level="ERROR"/> <!-- flush buffer if an event with ERROR
level is enqueued -->
<AppenderRef ref="errors"/> <!-- where the send the buffer contents
to -->
</TimeMachineBuffer>
</Appenders>
<Loggers>
<Root level="trace">
<AppenderRef ref="timeMachine" level="trace" />
<AppenderRef ref="file" level="info" />
<AppenderRef ref="console" level="info" />
</Root>
</Loggers>
</Configuration>
{noformat}
> 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
