I'm currently investigating the Smallrye Reactive Messaging integration in Quarkus.Sending and receiving messages is really simple and elegant at first glance.
But one thing which I didn't find out is: How to handle a re-delivery of messages?
Example: We receive a message and try to process it. Some exception (maybe a DB not available or an optimistic lock exception or something) happens.
In such a case I would throw an exception so that the message is not acknowledged. But currently I see no way how the message is redelivered.
I set-up a small dummy project to test this:
Quarkus
ActiveMQ Artemis
send a message (via Artemis console) into a queue
-- queue configured with max redelivery = 3
receive the message with Quarkus / Smallrye Reactive Messaging #Incoming annotation
throw exception in the #Incoming method
--> Message is removed from the Artemis queue
--> #Incoming method is only called once
If I shutdown the Quarkus App, the message can be seen again in the Artemis queue with redelivered flag set to true.
But I find no way how I can manage/configure a redelivery in the Smallrye Reactive Messaging so that this layer handles the redelivery of a message for n times and puts the message into a DLQ after the max retries.
Is there any way to do this?
Related
How can we implement redelivery policy from consumer side with stomp in ActiveMQ?
Is it even be possible?
Yes. Look to using the local transaction support in STOMP. This will enable you to commit and rollback messages to provide a redelivery pattern.
A recommended consumer error handling pattern:
If the message is invalid (ie.. bad JSON or XML) move to DLQ immediately. The message will never improve in quality and there is no reason to do repeated retries.
If the 'next step' in processing is down (ie. the database) reject delivery and the implement a delay between your next receive() call and track a retry limit to provide an escape hatch. This also has the benefit of allowing other consumers on the queue to attempt processing the message and eliminates the problem where one consumer has a dead path from holding up a messages.
I am using Spring JMS with TIBCO EMS queue/topic for my spring boot application. The TIBCO EMS queue is setup with EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE. In my code, I am not setting the acknowledgment mode, so I assume spring will take it s default AUTO_ACKNOWLEDGE. The behavior I notice in my listener onMessage method is, if the application successfully process the message, no redelivery of the same message And if the application throws a RuntimeException, there is a redelivery of the same message. The code is also with setSessionTransacted to true with DefaultJmsListenerContainerFactory. In this scenario, is the spring actually acknowledging the message on my behalf or do the code need to set the message.acknowledge().
See the javadocs for Session. Auto means the provider library automatically acks the message when consumer.receive() returns it, or the consumer.messsageListener() exits.
With a SimpleMessageListenerContainer, your listener is called directly by the provider's Consumer so messages won't be auto-ack'd until your listener exits normally.
The DirectMessageListenerContainer calls receive() instead and calls your listener on its own thread. Hence we need transactions to roll back the ack after an exception is thrown.
Please guide me as how to configure a DLQ for the failed message processing in Spring Boot JMS. I would like to send the failed messages to DLQ based on the error type. Ex, business error - send to DLQ, technical error - discard...
I found the solution. It should be through the JMS provider, in my case I had to configure a Backout queue for the listener queue and DLQ at the queue manager level
We are using Solace as messaging broker. How can I get the number of times a message is delivered from broker? In Jboss, there is a property called JMSXDeliveryCount. Is there anything similar in Solace?
The Solace JMS API is compliant with JMS1.1.
Unfortunately, JMSXDeliveryCount is an optional property in the JMS1.1 specification that is not implemented by the Solace JMS API.
For now, you can keep track of redelivered messages with JMSRedelivered, which does not provide the count.
If you are worried about application handling of "poisonous" messages - messages which cannot be consumed for some reason and need to be redelivered, you can make use of the "Max Redelivery" feature on the Solace endpoints. Messages will be moved to the Dead Message Queue or even configured to be discarded, when the message has been redelivered above the "Max Redelivery" count.
Support for JMSXDeliveryCount is in Solace's feature candidate list, and is likely to be implemented in a future release.
This is not totally on JMS Queue handler test. So, continue reading.
We have an architecture where spring channel listens to a queue from ActiveMQ. The listener of this queue will receive messages and has a static list of sub-listeners (identified by unique subjects). All the messages will have some parameters including the subject to which this message has to be delivered.
SMSService will drop its messages to the activemq with a subject SEND_SMS. It will be listened either by some HTTP Service or SMPP Service. You can even design your own Listener and wire that as a spring component with the required "subject".
Problem:
There is a better chance that this internal subject might change. This doesn't even throw an explicit Runtime Exception when there are no listeners. Is there a way to test this message being actually received by the intended listener?
`
As tim Bish siad, your problem statement is much too vague.
Have you tried to create your own ActivemMQ interceptor (I do not know if it could be usefull for your problem)