AbstractMethodMessageHandler does not rethrow Errors [SPR-16912] #21451
Labels
in: messaging
Issues in messaging modules (jms, messaging)
status: backported
An issue that has been backported to maintenance branches
type: bug
A general bug
Milestone
Bernhard Streit opened SPR-16912 and commented
We're using Spring Cloud AWS to receive messages from SQS.
Now, due to a bug, one of our services threw an OutOfMemoryError.
Having a redrive policy to a dead-letter queue set on the SQS queue, I assumed that with deletion policy NO_REDRIVE, the messages would get returned to the queue.
But that is not happening, as the AbstractMethodMessageHandler, that re-throws exceptions in case they occur, does not do that with errors (to be more precise, with all Throwables that are not of type Exception):
That has the effect that the SimpleMessageListenerContainer of Spring Cloud AWS Messaging assumes the execution finished without any error, and hence deletes the message from the queue:
executeMessage() returns silently, as the throwable was swallowed, and hence, applyDeletionPolicyOnSuccess() is executed next.
In case of an Exception, it would execute applyDeletionPolicyOnError, but not in case of an error.
Question: Is the Spring Framework violating the contract, by swallowing the Error? IMHO it should be re-thrown, just like ordinary Exceptions are.
Or is the SimpleMessageListenerContainer wrong to assume that if executeMessage has returned normally, the processing went fine without any problem? If yes, how can it figure out that an error has occurred?
Affects: 4.3.17, 5.0.6
Issue Links:
@ExceptionHandler
cannot handler java.lang.Error despite the annotation accept ? extends Throwable@MessageExceptionHandler
should match cause as well (analogous to@ExceptionHandler
)Referenced from: commits 1d6f717, f39adcf, 0c8cfa0, 646d7f9
Backported to: 4.3.18
The text was updated successfully, but these errors were encountered: