Bug 614684

Summary:	JMS Client should implement the reliability option from the new addressing scheme
Product:	Red Hat Enterprise MRG	Reporter:	Rajith Attapattu <rattapat+nobody>
Component:	qpid-java	Assignee:	Rajith Attapattu <rattapat+nobody>
Status:	CLOSED CURRENTRELEASE	QA Contact:	MRG Quality Engineering <mrgqe-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	Development	CC:	gsim, tross
Target Milestone:	Next Version
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-29 20:10:25 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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:
N/A

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

Expected results:
N/A

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.