[
https://issues.apache.org/jira/browse/LOG4J2-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15477155#comment-15477155
]
Remko Popma commented on LOG4J2-1349:
-------------------------------------
(Away from PC, these are notes to myself and I will delete this comment later,
please ignore)
thread-context.xml
<h4>Non thread-local context data </h4>
<p>
The ThreadContext allows us to tag logging statements so we can
link log entries that were related
in some way. The limitation is that this only works for logging
done on the same application thread
(or child threads when configured).
</p>
<p>
Some applications have a thread model that delegates work to
other threads, and
in such models, tagging attributes that are put into a
thread-local map in one thread are not visible
in the other threads and logging done in the other threads will
not show these attributes.
</p>
<p>
Log4j 2.7 adds a flexible mechanism to tag logging statements
with context data coming from
other sources than the ThreadContext.
See the manual page on <a
href="extending.html#Custom_ContextDataInjector">extending Log4j</a> for
details.
</p>
extending.xml
<subsection name="Custom ContextDataInjector">
<p>
The <code>ContextDataInjector</code> (introduced in Log4j 2.7)
is responsible for
populating the LogEvent's <code>ContextData</code> with
key-value pairs
or replacing it completely.
The default implementation is ThreadContextDataInjector, which
obtains context attributes from the ThreadContext.
</p><p>
Applications may replace the default ContextDataInjector by
setting the value of the system property
log4j2.ContextDataInjector to the name of the custom
ContextDataInjector class.
</p><p>
Implementors should be aware there are some subtleties related to
thread-safety and implementing a
context data injector in a garbage-free manner.
See the <a class="javadoc"
href="../log4j-core/apidocs/org/apache/logging/log4j/core/impl/ContextDataInjector.html">ContextDataInjector</a>
javadoc for detail.
</p>
</subsection>
> Garbage-free ThreadContext map
> ------------------------------
>
> Key: LOG4J2-1349
> URL: https://issues.apache.org/jira/browse/LOG4J2-1349
> Project: Log4j 2
> Issue Type: Improvement
> Components: API
> Affects Versions: 2.5
> Reporter: Remko Popma
> Assignee: Remko Popma
> Fix For: 2.7
>
> Attachments: DataStructOpsPerfMediumDataSet.png,
> DataStructOpsPerfSmallDataSet.png, InjectWithConfigProperties.png,
> InjectWithoutConfigProperties.png, ThreadContextPut.png,
> v2_DataStructOpsPerfMediumDataSet.png, v2_DataStructOpsPerfSmallDataSet.png,
> v2_InjectWithConfigProperties.png, v2_InjectWithoutConfigProperties.png,
> v2_ThreadContextGet.png, v2_ThreadContextPut.png
>
>
> The current ThreadContext map and stack implementations allocate temporary
> objects. This ticket is to investigate and track the work for alternative
> implementations that are garbage-free.
> Both DefaultThreadContextMap and DefaultThreadContextStack are copy-on-write
> data structures: each modification replaces the ThreadLocal object with a
> modified copy. The advantage of this approach is that there is no need to
> make a copy for each LogEvent.
> Also, DefaultThreadContextMap uses a JDK map, the JDK collections tend to
> allocate a lot of temporary objects.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
