Red Hat Bugzilla – Bug 614684
JMS Client should implement the reliability option from the new addressing scheme
Last modified: 2012-03-29 16:10:25 EDT
Description of problem:
The new addressing scheme defines the following reliability modes.
unreliable: there may be duplicate messages, and there may also be missing messages
at-most-once: there may be missing messages, but there will be no duplicate messages
at-least-once: there may be duplicate messages, but there will be no missing messages
exactly-once: there will be no missing or duplicate messages
The mapping to the 0-10 protocol is as follows.
1. For at-most-once (and unreliable) we need to use accept-mode=none.
2. For at-least-once we use non auto-delete (i.e. auto-delete=*false*), and accept-mode=explicit
3. exactly-once is not yet supported.
The default reliability mode is at-least-once.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
We would need to think through the implications when requesting durable subscriptions, particular acking modes etc. I.e. cases where the intention as signalled through JMS API differs from that indicated in the address.
A fix has been made in upstream at http://svn.apache.org/viewvc?rev=1076800&view=rev
The Reliability option was implemented as follows.
Only UNRELIABLE and AT_LEAST_ONCE is supported and the reliability mode is used only for determining the accept-mode.
It would have been nice if we had a way to determine the life time of a temp queue (topics) using the reliability mode. That is if reliability mode is -at-least-once the queue is marked auto-delete false and will only be deleted when the consumer invokes close rather than when the connection is lost.
Therefore a topic created with at-least-once will will be resilient to connection losses due to temporary network issues. If the queue was marked durable it would survive broker crashes as well.
However due to the way the current code base is structured this cannot be easily implemented without substantial code changes. The above behaviour conflicts with DurableSubscriptions as current the code does not really distinguish between a durable subscription and a regular subscription.