[
https://issues.apache.org/jira/browse/LOG4J2-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LOG4J2-1258:
---------------------------------
Description:
Using Log4J 2.5 with {{AsyncLogger}} mode enabled. Filtering events at the
{{Appender}} level using {{DynamicThresholdFilter}} is not working.The filter
is basing its decision on the {{ThreadContext}} even though it is filtering an
asynchronous event on a worker thread.
{code:java}
private Result filter(final Level level) {
final Object value = ThreadContext.get(key); // always returns null,
ThreadContext is empty on disruptor thread
if (value != null) {
…
{code}
Fixing the DynamicThresholdFilter to use the context from the log event instead
produces the expected filtering behavior :
{code:java}
private Result filter(final Level level, Map<String, String> context) {
final Object value = context.get(key);
if (value != null) {
…
public Result filter(final LogEvent event) {
return filter(event.getLevel(), event.getContextMap());
}
public Result filter(final Logger logger, final Level level, final Marker
marker, final Message msg,
final Throwable t) {
return filter(level, ThreadContext.getContext());
}
{code}
{{ThreadContextMapFilter}} is built the same way.
was:
Using Log4J 2.5 with AsyncLogger mode enabled. Filtering events at the Appender
level using DynamicThresholdFilter is not working.The filter is basing its
decision on the ThreadContext even though it is filtering an asynchronous event
on a worker thread.
private Result filter(final Level level) {
final Object value = ThreadContext.get(key); // always returns null,
ThreadContext is empty on disruptor thread
if (value != null) {
…
Fixing the DynamicThresholdFilter to use the context from the log event instead
produces the expected filtering behavior :
private Result filter(final Level level, Map<String, String> context) {
final Object value = context.get(key);
if (value != null) {
…
public Result filter(final LogEvent event) {
return filter(event.getLevel(), event.getContextMap());
}
public Result filter(final Logger logger, final Level level, final Marker
marker, final Message msg,
final Throwable t) {
return filter(level, ThreadContext.getContext());
}
ThreadContextMapFilter is built the same way.
> Async DynamicThresholdFilter does not use the log event's context map
> ---------------------------------------------------------------------
>
> Key: LOG4J2-1258
> URL: https://issues.apache.org/jira/browse/LOG4J2-1258
> Project: Log4j 2
> Issue Type: Bug
> Components: Filters
> Affects Versions: 2.5
> Environment:
> -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
> Reporter: Francis Lalonde
> Priority: Minor
> Labels: newbie
> Fix For: 2.5.1
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Using Log4J 2.5 with {{AsyncLogger}} mode enabled. Filtering events at the
> {{Appender}} level using {{DynamicThresholdFilter}} is not working.The filter
> is basing its decision on the {{ThreadContext}} even though it is filtering
> an asynchronous event on a worker thread.
> {code:java}
> private Result filter(final Level level) {
> final Object value = ThreadContext.get(key); // always returns null,
> ThreadContext is empty on disruptor thread
> if (value != null) {
> …
> {code}
> Fixing the DynamicThresholdFilter to use the context from the log event
> instead produces the expected filtering behavior :
> {code:java}
> private Result filter(final Level level, Map<String, String> context) {
> final Object value = context.get(key);
> if (value != null) {
> …
> public Result filter(final LogEvent event) {
> return filter(event.getLevel(), event.getContextMap());
> }
> public Result filter(final Logger logger, final Level level, final Marker
> marker, final Message msg,
> final Throwable t) {
> return filter(level, ThreadContext.getContext());
> }
> {code}
> {{ThreadContextMapFilter}} is built the same way.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
