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.
Related
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?
We have a discard channel for some filters and aggregators, but we have seen that discard channel is a regular direct channel.
So, where those discarded messages go ? to DLQ ?
And also, do they live forever there ? Because we are struggling with memory consumption and we would like those messages to be deleted (garbage collected ) as soon they arrive to the DLQ.
Even if Spring Integration is based on the Messaging concepts, it is just a tool to build integration solutions. It isn't a Broker and therefore doesn't provide out-of-the-box state management like queue persistence and DLQ.
You are correct, the discardChannel is just a MessageChannel and you can inject any implementation there and do some desired logic in the discard flow on that channel. Sending to DLQ is already your particular use-case and you really should do that manually. There is nothing specific for Spring Integration on that discard channel. And if it is just regular QueueChannel without any poller on the matter, you really end up once with the OOM because messages are stored in the memory forever.
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.
I am currently working on an application with Spring Integration. The application requires guaranteed delivery and the option that the it will be functional for a specific amount of time that the external systems are unavailable without losing messages. Channels will be JMS backed with expiration time. I would like to understand which is the best practice for redelivery with Spring Integration. We are having the following options:
The application's integration flow has a number of outbound message gateways that requires RPC calls with external system. Statefull retry advice can be used. After the max attemps is reached for specific runtime exceptions the message will be addressed to a recovery channel. The recovery channel will use a delayer and will then address the message back to the original channel. After X times that the message will reach the recovery channel it will be addressed to the error channel where it will be simply logged without further processing. The delayer component in this case should use the jdbc message store option.
Another option would be to use the standard JMS option for redelivery. In this case the redelivery policy will not be implemented on Spring Integration but on the JMS provider side.
Which is the best practice for message redelivery with Spring Integration?
I'd say like this: don't reinvent the wheel!
If there is already some similar solution on the matter, just use it as is with its specific configuration.
Right, if JMS has that solution, just go ahead.
There is need, of course, to get deal with DLQ in case of message expiration or redelivery exhausting. But the concept is here.
I am developing an application in which I have jms message queue.
There is a producer which enqueue message to the queue and a consumer to dequeue the message.
There might be cases when consumer is not running. If a message is not consumed by the consumer within a certain amount of time I need to catch that from producer.
I want to use JMX to monitor message queue's message whether it is expired.
Any suggestion or sample code how to this.....
It depends on the JMX implementer... Some servers provide JMX implementations to monitor its resources. If its not provided, then you will need to write the JMX implementation that uses the API provided by the MQ implementer.
An easier way to solve this problem is to use the request-response pattern with expiry. The consumer needs to respond in a specified internal of time. If it can't then the message on the queue can expire. If the response is not received the producer can take further action. JMS selector with correlation ID can be used to relate the responses with the request.