Bug 748990 - 2.5 Sender Capacity and Replay needs more coding details.
Summary: 2.5 Sender Capacity and Replay needs more coding details.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: Messaging_Programming_Reference
Version: 2.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: 2.2
: ---
Assignee: Joshua Wulf
QA Contact: ecs-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-25 19:26 UTC by William Henry
Modified: 2014-10-19 22:59 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-20 03:13:18 UTC
Target Upstream Version:


Attachments (Terms of Use)
Modified section 2.5 with code examples. (14.85 KB, application/vnd.oasis.opendocument.text)
2011-10-28 23:19 UTC, William Henry
no flags Details

Description William Henry 2011-10-25 19:26:21 UTC
Description of problem:

Section 2.5 Sender Capacity and Replay requires more details.  At no point does it show how to program sending asynchronous messages and doesn't show the code to check the available capacity or the unsettled messages.

Example this paragraph requires more details:
"The sender can be queried for the available space (the unused capacity), and for the current count of unsettled messages (those held in the replay list pending confirmation by the server). When the unsettled count is zero, all messages on that sender have been successfully sent."

Something like this would be better:
"The sender can be queried for the available space (the unused capacity) using the Sender class method getAvailable(). The current count of unsettled messages (those held in the replay list pending confirmation by the server) can be checked using the Sender class method getUnsettled()." 

It should include some coding example and explicitly mention the appropriate methods and classes. 

Some notes below on an example.

Depending on what you want to do the following is helpful. Assume you've setCapacity to some number.

e.g. sender.setCapacity(MY_CAPACITY);  // set MY_CAPACITY set using and arg 
                                       // not using a #define ;-)

Then:
        bool resend = true;
        while (resend)
        {
          if (sender.getAvailable()>0)
          {
            sender.send(message,false);
            resend = false;
          }
          else
          {
            //  May wish to do nothing here or send to log
            std::cout << "Warning: Capacity full. Retry" << std::endl;
          }
        }

You can check how many are outstanding by using getUnsettled().

e.g. at the end you might want to:

if (sender.getUnsettled())
{
    session.synch();
} 


I will try to rewrite this section and add examples. I'll upload a doc with the info because I may wish to include a table with C++ and Python APIs.

BTW what does a Java developer do for this? Is it part of JMS?  I don't remember MessageProducer having such an API.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 William Henry 2011-10-28 23:19:06 UTC
Created attachment 530750 [details]
Modified section 2.5 with code examples.

Comment 2 William Henry 2011-11-01 16:47:20 UTC
In my attached document I have in the C++ part of the table:

// Later
if (sender.getUnsettled())
{
    session.synch();
} 

Instead it should be:

// Later
if (sender.getUnsettled())
{
    session.sync();
} 


Notice the removal of the 'h' from synch() to sync().

Comment 4 Joshua Wulf 2012-07-15 12:08:22 UTC
Interestingly, the Python API docs do not list a capacity property for a sender object, although it is mentioned in the send method:

http://qpid.apache.org/apis/0.14/python/html/qpid.messaging.endpoints.Sender-class.html

Comment 9 Joshua Wulf 2012-08-27 03:15:43 UTC
It is incorporated, it's attached to the bug for future reference.

Comment 12 Cheryn Tan 2012-09-20 02:53:53 UTC
Released for MRG 2.2


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