I am using Spring Cloud Stream and spring-cloud-stream-binder-kafka, version 4.1.2.
I created and configured a custom error handler: spring.cloud.stream.bindings.consumer1-in-0.error-handler-definition=myErrorHandler
When "consumer1" processes a message, it simply throws a RuntimeException. In the log, the default org.springframework.integration.handler.LoggingHandler is run firstly, then the custom error handler "myErrorHandler" is run secondly.
Accroding to https://docs.spring.io/spring-cloud-stream/reference/spring-cloud-stream/overview-error-handling.html#handle-error-messages: "NOTE: Custom error handler is mutually exclusive with framework provided error handlers (i.e., logging and binder error handler - see previous section) to ensure that they do not interfere.":
Anyone knows why the default LoggingHandler is still run and how to disable it?
The behavior you are seeing is the expected one. The logging handler stack trace is independent of any binder or Spring Cloud Stream-specific error handling. It means the consumer threw an exception, and the Spring Integration infrastructure caught it and logged it via the Spring Integration errorChannel.
When you don't provide a custom error-handler-definition in Spring Cloud stream, i.e., leave it to the defaults, it triggers the default error handling in Spring Cloud Stream. In this case, any message sent to the Spring Integration error channel is sent to the binder error channel, which a Spring Cloud Stream internal error handler. This is the error handler that is overridden by the binder-specific DLQ mechanism (when the binder error handling is not active, then the default one in the core Spring Cloud Stream framework will kick in) . Coming back to your question, when you don't have error-handler-definition, you will see more logging in addition to the one from the LoggingHandler. In the case of the Kafka binder, you will see the DefaultErrorHandler logging from Spring for Apache Kafka since that is where the binder error channel is ultimately bound (but that is just an internal implementation detail). However, when you provide an error-handler-definition, you should not see this binder error handler but your custom error handling. This is what the ref docs talk about as mutually exclusive. That said, we need to update the docs to reflect this behavior properly.
The upshot here is that you will always see the LoggingHandler message from Spring Integration, but when you use the custom error handler, any default Spring Cloud Stream-specific error handling should not trigger.