I'm having a problem using the logback filters, below I leave the configuration of my appender .
<appender name="console" class="ar.com.custom.logging.logback.UdpAppender">
<filter class="ch.qos.logback.core.filter.EvaluatorFilter">
<evaluator> <!-- defaults to type ch.qos.logback.classic.boolex.JaninoEventEvaluator -->
<expression>return formattedMessage.contains("Cadena no deseada");</expression>
</evaluator>
<OnMismatch>NEUTRAL</OnMismatch>
<OnMatch>DENY</OnMatch>
</filter>
<addr>${logback.udp-ip}:${logback.udp-port}</addr>
<layout>
<pattern>\(${HOSTNAME}\) %d %-5level [%X{requestId}] [%thread] %logger{15} - %msg</pattern>
</layout>
</appender>
Basically when I run my webapp with something of 200 threads ready to listen to requests and it receives several requests concurrently this filter generates an exception in the class:
ch.qos.logback.core.boolex.JaninoEventEvaluatorBase::evaluate
The exception thrown is InvocationTargetException .
This causes that within the method evaluate
of the class JaninoEventEvaluatorBase
account for 4 exceptions and de-enable the filter causing it to stop filtering for the following records to persist.
- Can this behavior be avoided?
- is there another filter for regular expression that does not have this behavior?
The version of logback that I use is: 1.1.3 (It is not a version theme because I update the last one and it keeps happening this way)
[CLOSED]
The behavior that I described at the end is the correct one of the library, from our application we log some traces without sending a message (the message that arrives at the filter is null) and therefore after 4 repetitions de-enable the filter to avoid generating unnecessary errors. The solution was to always send a message and put an interceptor that ensures that all traces have a defined message.