Bug 614684 - JMS Client should implement the reliability option from the new addressing scheme
JMS Client should implement the reliability option from the new addressing sc...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-java (Show other bugs)
Development
All Linux
low Severity low
: Next Version
: ---
Assigned To: Rajith Attapattu
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-14 20:52 EDT by Rajith Attapattu
Modified: 2012-03-29 16:10 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-03-29 16:10:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rajith Attapattu 2010-07-14 20:52:53 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):


How reproducible:
N/A

Steps to Reproduce:
N/A
  
Actual results:
N/A

Expected results:
N/A

Additional info:
Comment 1 Gordon Sim 2010-07-16 03:51:57 EDT
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 11:28:36 EST
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.