Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AbstractAdaptableMessageListener should not "eat" exceptions in the onMessage() [SPR-14473] #19042

Closed
spring-issuemaster opened this issue Jul 15, 2016 · 2 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jul 15, 2016

Artem Bilan opened SPR-14473 and commented

It isn't clear why originally the logic in the AbstractAdaptableMessageListener has been chosen like:

try {
	onMessage(message, null);
}
catch (Throwable ex) {
	handleListenerException(ex);
}

where the last one just logs an exception:

logger.error("Listener execution failed", ex);

but that looks inconsistent with the onMessage(Message message, Session session). Especially when some custom wrapper decides to delegate to this onMessage(Message) and won't be able to see exception handling in the container.

In Spring Kafka (spring-projects/spring-kafka#150) and Spring AMQP (https://jira.spring.io/browse/AMQP-623) we concluded always throw exception in the default AbstractAdaptableMessageListener logic.
Any custom implementation may choose to use that "odd" handleListenerException(ex) method.


Affects: 4.3.1

Issue Links:

  • AMQP-623 AbstractAdaptableMessageListener should not "eat" exceptions in the onMessage()
@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 15, 2016

Juergen Hoeller commented

This is by design: In a Spring scenario, we're always calling onMessage(message, session) anyway, handling any exceptions in our listener container infrastructure. In fact, the plain onMessage(message) method is just there to satisfy the JMS MessageListener interface, for use with other JMS infrastructure or for direct use with a JMS provider.

Now, the JMS spec has the following to say about the MessageListener contract:
"It is possible for a listener to throw a RuntimeException; however, this is considered a client programming error. Well-behaved listeners should catch such exceptions and attempt to divert messages causing them to some form of application-specific unprocessable message destination."

Concretely, in an EJB MDB scenario, an exception leads to a hard remove of the misbehaving MDB instance. So we're just being defensive there and following the "well-behaved listeners" rule.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 15, 2016

Artem Bilan commented

Fair enough Juergen! Thank you.
Fortunately it isn't a case for Spring AMQP and Spring Kafka and that MessageListener abstraction is our own invention and it is a part of our container API to handle exceptions properly.
So, now I'm sure that handleListenerException is there by mistake during API porting from Spring JMS. And I more and more feel like we should deprecate and do not lure end-users to utilize it in their code.
Cheers and thank you for your time!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.