Bug 614684 - JMS Client should implement the reliability option from the new addressing scheme
Summary: JMS Client should implement the reliability option from the new addressing sc...
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java
Version: Development
Hardware: All
OS: Linux
Target Milestone: Next Version
: ---
Assignee: Rajith Attapattu
QA Contact: MRG Quality Engineering
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-15 00:52 UTC by Rajith Attapattu
Modified: 2012-03-29 20:10 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2012-03-29 20:10:25 UTC

Attachments (Terms of Use)

Description Rajith Attapattu 2010-07-15 00:52:53 UTC
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):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Gordon Sim 2010-07-16 07:51:57 UTC
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.

Comment 2 Rajith Attapattu 2011-03-07 16:28:36 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.