[
https://issues.apache.org/jira/browse/LOG4J2-1401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15307922#comment-15307922
]
Ralph Goers commented on LOG4J2-1401:
-------------------------------------
I don't remember if I created a Jira, but I had planned to create a component
that would have a set of ring buffers. Events would be saved in the ring buffer
until some triggering event occurred. At that time the events in the current
ring buffer would be logged while new events are routed into the second ring
buffer. Multiple ring buffers would be necessary to account for some number of
triggering events occurring in rapid succession. The trigger itself should be
a plugin and would probably be what you would want to focus on in this
solution. I am not sure if this component would be an Appender or something
new.
The point of doing it this way is that you can have logging virtually turned
off until a triggering event occurs, at which time all the events in the ring
buffer would be logged. So you could log at the trace level but only have the
last 500, 1,000 or whatever number of events "printed" when an error occurs, or
whatever the trigger is.
An enhancement to this would be to have a ring buffer per user, company, or
some other entity the user wants so that only the events for that entity are
logged when the trigger is fired.
> Support changing the log level for all messages related to some domain object
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-1401
> URL: https://issues.apache.org/jira/browse/LOG4J2-1401
> Project: Log4j 2
> Issue Type: New Feature
> Components: Core, Filters
> Affects Versions: 2.6
> Reporter: Remko Popma
>
> During system operations, it is commonly desirable to temporarily make
> logging for a certain domain object more verbose. For example, all log
> messages related to processing a certain order, or for a certain user, or for
> a certain product.
> In addition to manually increasing/decreasing verbosity, it would be nice if
> we can restore the original verbosity if some condition no longer holds. For
> example, log at some verbose level
> * for some period of time (5 minutes)
> * for some fixed number of events (10,000 log messages)
> * any other user-specified condition
> *How to identify which log messages to log at more verbose level*
> * Marker
> * ThreadContext map
> * Other?
> Markers are cached forever, which may not be desirable if we need to tag
> every log message with the order ID, user ID and/or product ID.
> ThreadContext is a good option since values can be replaced and/or cleared so
> we don't use up increasingly more memory. The drawback of the ThreadContext
> API is that values must be Strings.
> We would like the ability to specify arbitrary Object values, or even
> primitive values. Also, ideally this should be garbage-free (LOG4J2-1349).
> *Considerations for a new or extended ThreadContext*
> * Adding or setting values: what should the user-facing API look like?
> * Merging the snapshot of the current ThreadContext map with the
> Configuration Properties into the LogEvent map
> * Getting values out of the LogEvent for use by Filters and/or Layouts. This
> may be by a specified key or by iterating over the keys.
--
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
