0

I have a filter which is suppressing repeated messages, if the message was seen more than x times within y seconds for z seconds. With log4j I've put a event scoped MDC property to it once the threshold was reached, like:

event.setProperty( "prefix", suppressProlog );

In my layouts I used then this kind of pattern:

<param name="ConversionPattern" value="[%d{yyyy-MM-dd HH:mm:ss.SSS z}] %p %t %c %X{prefix} %m%n" />

As this property was limited to the current event, I hadn't to worry about cleaning up. With log4j2, it seems that event linked properties are gone. How would I realize the same behaviour as I had with log4j?

Here's what I see as possible solutions, but none looks very appealing to me:

  • I could keep my own ThreadLocal property and clean it up after it was logged, but what when it's being logged through Async Logger within another Thread, or how do I know that this can be cleaned up? And splitting the suppression logic into Filter and Layout seems wrong
  • Reading this answer https://stackoverflow.com/a/29597669/1377224, it seems like subclassing LogEvent is discouraged either, so extending LogEvent to provide some suppress flag isn't working. As well I tried to keep away from hacking into log4j this time.
  • The filter could log itself a message telling that message x is going to be suppressed. Would it be good practice to have plugins log messages with standard loggers instead of StatusLogger?

What is the anticipated pattern to have filter influence, the logging output?

Community
  • 1
  • 1
philnate
  • 1,506
  • 2
  • 21
  • 39
  • Could you not capture the log message and implement your suppression at the filter level with custom filter plugin? Memory/performance issues would be my main concern, but i think it would work. – alan7678 Sep 30 '15 at 05:44
  • Hi @alan7678, I plan to have this as filter, just as I did with log4j. The actual suppression isn't the issue. The troublemaker is that I can't find a way to log the message with some adjusted message string, informing the user about the starting suppression of the log message. Another option could be to simple have the filter log another message about the suppression. – philnate Sep 30 '15 at 07:43
  • That seems like a reasonably good idea to me. You can get the logger name from the event I believe. – alan7678 Oct 01 '15 at 04:07
  • @alan7678 just tried to create a new Log message from within my filter. Log4j2 is actively checking that no StackOverflow can happen due to bad logging. So this approach won't work either. – philnate Nov 18 '15 at 15:41
  • Maybe you could use the thread context with a pattern converter. The filter could suppress messages and store an object with info about the suppression in the thread context. A custom pattern converter could then check the thread context for the object and decide to append useful info to the log message. It feels kinda hacky but it might work. – alan7678 Nov 20 '15 at 19:09
  • I don't really know if you can modify variables in the thread context within a filter though. – alan7678 Nov 20 '15 at 19:10

1 Answers1

0

The sourcecode of the LoggerEvent shows that under the hood of the getProperty and setProperty methods it was using the MDC to store and get the properties.

The new class LogEvent has the Map getContextMap()

This is the replacement from my POV.

danidacila
  • 147
  • 1
  • 3