Bug 1152589

Summary: Incorrect footnote related to reliability options
Product: Red Hat Enterprise MRG Reporter: Petr Matousek <pematous>
Component: Messaging_Programming_ReferenceAssignee: Jared MORGAN <jmorgan>
Status: CLOSED ERRATA QA Contact: Petr Matousek <pematous>
Severity: low Docs Contact:
Priority: unspecified    
Version: 3.0CC: jmorgan, mmurray, zkraus
Target Milestone: 3.1   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1152590 (view as bug list) Environment:
Last Closed: 2015-04-14 13:48:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1152590    

Description Petr Matousek 2014-10-14 13:31:46 UTC
Description of problem:

Incorrect text listed in '11.4. Link Properties' table footnote:

a] If at-most-once is requested, unreliable will be used and for durable messages on durable queues there is the possibility that messages will be redelivered; if exactly-once is requested, at-most-once will be used and the application needs to be able to deal with duplicates. 

shall be updated following way:

... if exactly-once is requested, at-least-once will be used and the application needs to be able to deal with duplicates. 

Version-Release number of selected component (if applicable):
Red Hat Enterprise MRG 3 - Messaging Programming Reference
Revision 3.0.0-4

How reproducible:
100%

Steps to Reproduce:
n/a

Actual results:
Wrong information listed in the table 4.11 cfootnote

Expected results:
Correct information listed in the table 4.11 footnote

Additional info:

Comment 3 Petr Matousek 2014-12-19 11:35:45 UTC
Thanks for the logical separation, now it makes more sense. I have still noted following two discrepancies:

1.) I realized that the footnote was completely wrong (sorry for late notifying), following description is more appropriate:
[a] If at-most-once is requested, unreliable is used. There is a possibility that messages may be lost.
[b] If exactly-once is requested, at-least-once is used. There is a possibility that messages may be redelivered and the application itself must handle duplicates. 

Or we can completely remove the supplemental text, because the possibility of message loss and re-delivery is already described above in the table. So, the footnote may list just:

[a] If at-most-once is requested, unreliable is used.
[b] If exactly-once is requested, at-least-once is used.


2.) Following sentence (in the table) do not make much sense to me:
"Reliability indicates the level of reliability that the sender or receiver."

It should probably be something like following:
Reliability indicates the level of link reliability requested by the sender or receiver.

Comment 4 Jared MORGAN 2014-12-22 00:27:05 UTC
(In reply to Petr Matousek from comment #3)
> Thanks for the logical separation, now it makes more sense. I have still
> noted following two discrepancies:
> 
> 1.) I realized that the footnote was completely wrong (sorry for late
> notifying), following description is more appropriate:
> [a] If at-most-once is requested, unreliable is used. There is a possibility
> that messages may be lost.
> [b] If exactly-once is requested, at-least-once is used. There is a
> possibility that messages may be redelivered and the application itself must
> handle duplicates. 
> 
> Or we can completely remove the supplemental text, because the possibility
> of message loss and re-delivery is already described above in the table. So,
> the footnote may list just:
> 
> [a] If at-most-once is requested, unreliable is used.
> [b] If exactly-once is requested, at-least-once is used.
> 
> 
> 2.) Following sentence (in the table) do not make much sense to me:
> "Reliability indicates the level of reliability that the sender or receiver."
> 
> It should probably be something like following:
> Reliability indicates the level of link reliability requested by the sender
> or receiver.

And this is why information presentation is so important. So we can "see" the content. :D

I've taken the approach where we strip down the footnotes of their supplemental text, and let the main table body text define behavior. 

Thanks for the feedback as always Petr. Link in Comment #2 is valid for viewing the changes.

Comment 5 Petr Matousek 2014-12-22 09:47:58 UTC
Content Approved.

Comment 9 errata-xmlrpc 2015-04-14 13:48:29 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2015-0805.html