Since there is no getReceiptHandle method on the message, how to change the visibility timeout of an SQS message received using JMS Listener?
Related
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.
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?
According to the JMS spec, I do not have to specify the message ID when sending.
When I send a message via JMSProducer#send() or when I create a message via the hawt.io console, I can see the message ID being set to some internal sequential number generated by the Artemis broker.
However, when I use MessageConsumer#receive() or MessageListener#onMessage() to receive a Message, Message#getJMSMessageID() always returns null.
The only way I can receive a message with a non-null JMS message ID is by reading a message from a different (IBM) message queue and copying all its properties to the Artemis message before sending it.
I have tested this with both AMQ 7.3.0.GA and Apache ActiveMQ Artemis 2.6.2, with both native (org.apache.activemq.artemis-jms-client) and AMQP (org.apache.qpid.qpid-jms-client) clients.
Is there some configuration I must set on the broker to make it populate JMS message IDs correctly?
JMS Message ID is usually stored in a native Artemis header that is called userID
Messages sent via the management console do not populate userID
Messages sent via the Core JMS client do populate the message ID
Messages sent via the Qpid client populate a custom property NATIVE_MESSAGE_ID with the JMS message ID
There's no way to obtain the internal message ID via JMS
If you send a message via Qpid and read it via Core client or vice versa you will receive a null JMS message ID
I want to consume kafka messages from dlq and process them. Default configuration for them is to add a listener for dlq.
Problem: I want to manually(conditional) consume message whenever i get the alert for dlq message. ANy solution from stream listener?
Is there a way I can set some properties to disable DLQ for a queue from the client configuration. I use SpringJMS for configuring my listeners.
I looked at
http://activemq.apache.org/message-redelivery-and-dlq-handling.html but that looks to be on the ActiveMQ Server side. Can I set something like IndividualDeadLetterStrategy for connectionFactory or listenercontainer? In my case, just disabling it from the client for all messages sent from that client would do.
No, this is a Broker side configuration and cannot be tweaked from the client end.
ActiveMQ pushes messages into DLQ only if you are throwing an error from Message Listeners. So you can catch the exceptions and avoid pushing to DLQ