This content has been marked as final. Show 2 replies
I just double-checked, and as far as I can tell the options for setting a redelivery limit include programmatically on the Producer or by configuring an override on the Destination. Unfortunately, you need the override to only take effect if the delivery limit hasn't already been set. (If we had a default deliverylimit configurable on our connection factory, this would have done the trick.)
I think you've already hit upon the solution: your consumers can check each received message's JMSXDeliveryCount and act accordingly. It's fine for a consumer to use the JMS_BEA_RedeliveryLimit property see if the Limit has been set by a producer, and then check JMSXDeliveryCount to check the delivery count, but I'm not sure if the JMS_BEA_RedeliveryLimit property is set in older versions (8.1 may not have it for example).
As a refinement, you may want to use the WLMessageProducer forward() API. This is an alternative to send() that preserves the message-id and timestamp of a consumed message. I don't think forward() allows any modification of the consumed message before it's forwarded.
Hope this helps,
Edited by: Tom B on Feb 22, 2013 10:03 AM
Thank you Tom,
I finally decided to specify an expirationTime for my messages, directly on the queue's XML configuration. If i need a MAX redelivery limit, i set my expirationTime as MAX_LIMIT x REDELIVERY_DELAY, and set a "Redirect" expiration policy.
It's not the exact way to achieve that i would have desired, however it works.