SimpleMessageListenerContainer logging errors at DEBUG level #3008
Milestone
Comments
spring-builds
pushed a commit
that referenced
this issue
Mar 10, 2025
Fixes: #3008 Issue link: #3008 The real problem in consumer (e.g. `ClassCastException` mentioned in the issue) might be lost if DEBUG logging level is not enabled * Fix the first condition in the `SimpleMessageListenerContainer.logConsumerException()` to use `logger.warn()` as it was before #2278 fix (cherry picked from commit b55010f)
spring-builds
pushed a commit
that referenced
this issue
Mar 10, 2025
Fixes: #3008 Issue link: #3008 The real problem in consumer (e.g. `ClassCastException` mentioned in the issue) might be lost if DEBUG logging level is not enabled * Fix the first condition in the `SimpleMessageListenerContainer.logConsumerException()` to use `logger.warn()` as it was before #2278 fix (cherry picked from commit b55010f)
This was referenced Mar 10, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in #3007
Originally posted by raul-avila-ph March 10, 2025
As we explained in #3006, we had some issues trying to read the
countfield inx-deathheader. We have proposed a safer way to parse it.When we had the problem in production, it took some time to be detected, as the ClassCastException was logged at DEBUG level:
spring-amqp/spring-rabbit/src/main/java/org/springframework/amqp/rabbit/listener/SimpleMessageListenerContainer.java
Line 1601 in 355be1e
In this discussion we'd like to ask you if it'd be possible for the framework to log this kind of errors at the WARN or ERROR level, maybe filtering out exceptions that shouldn't create unnecessary noise. The fact that a ClassCastException was only logged at DEBUG level made it invisible for our monitoring systems and it delayed the process to diagnose the problem.
The text was updated successfully, but these errors were encountered: