Open ggallen opened 1 year ago
Thanks for the merge request!
Can you elaborate on the use-case where I, as a user, would want my message to expire before processing?
@olivergondza: I can try to take a stab at answering your question. Assume a situation where a sender is expecting that a certain message is received and processed in some predetermined time by a known consumer. If the message is not processed in that time by the known consumer, the sender retries and resends another message. The sender continues to send the message until the message is processed by its known consumer. If in situations like these, the default value for message expiration is higher than what the sender is willing to wait for, the queue gets flooded with multiple duplicate messages and ends up inundating the consumer with additional burden of processing duplicate messages. If the code allows the sender to override the expiration time with its own custom value, then it will allow the messaging provider to drop the messages that have expired and reduce the overall processing burden on the consumer.
Is the millisecond resolution truly adequate? Given this is not expected to use sub-second (/sub-minute) times, let's use seconds/minutes instead.
@olivergondza , I changed to minutes in my latest push.
Only after reading https://stackoverflow.com/questions/31709353/jms-messageproducer-settimetolive-vs-textmessage-setjmsexpiration did I understand why you chose to set the time-to-live and not the JMSExpiration. Great job with the changes. Looking forward to seeing them get merged soon.
Allow clients to specify a message time-to-live (in milliseconds) when publishing a messsage.