[
https://issues.apache.org/jira/browse/LOG4J2-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007049#comment-14007049
]
Remko Popma commented on LOG4J2-643:
------------------------------------
No, the design makes that difficult if not impossible: with
AsyncLoggerContextSelector, the ringbuffer is pre-allocated with
RingBufferLogEvents. So during the life of the system, no new
RingBufferLogEvents are created (which means they don't need to be garbage
collected).
As an alternative, (just throwing out an idea, not sure if this will work) you
could consider having a custom ThreadContextMap. You can do this by setting
system property "log4j2.threadContextMap" to the fully qualified name of a
class that implements the {{org.apache.logging.log4j.spi.ThreadContextMap}}
interface.
Yet another idea is to use a logger wrapper.
> LogEventFactory not called when using AsyncContextSelector
> ----------------------------------------------------------
>
> Key: LOG4J2-643
> URL: https://issues.apache.org/jira/browse/LOG4J2-643
> Project: Log4j 2
> Issue Type: Improvement
> Components: Core
> Affects Versions: 2.0-rc2
> Reporter: Stefan Wehner
> Priority: Minor
>
> We're using the JDBCAppender to write log messages to a MySQL database -
> including some data provided by the ThreadContext.
> We wanted to make sure that at least some default values are available in the
> Event's MDC in case the values are not provided in the ThreadContext We also
> calculate some extra data (delta of the log event's time from the request
> start time - stored in the ThreadContext).
> We thought a good idea would be to do this in a custom LogEventFactory, that
> makes sure that values are set, provides defaults, and calculates the offset.
> When switching to using the AsyncLoggerContext this doesn't work anymore,
> because the LogEventFactory is not used (unless the RingBuffer is full - see
> AsyncLogger:248).
> I'm not sure if we're abusing the LogEventFactory here for something that it
> wasn't meant to do...
> If you think this is a legit use case: shouldn't the async logging also use
> this factory somehow? I understand the biggest problem of using the
> LogEventFactory to create an event, and then pass the values to the
> translator would be the context stack, which is handled differently in the
> AsyncLogger and the Log4jLogEvent constructor.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
