Bug 1123769 - [AMQP 1.0] Many QMF statistics for Connection class not updated for AMQP 1.0
Summary: [AMQP 1.0] Many QMF statistics for Connection class not updated for AMQP 1.0
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 3.0
Hardware: All
OS: All
medium
medium
Target Milestone: 3.3
: ---
Assignee: Gordon Sim
QA Contact: Messaging QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-28 08:43 UTC by Pavel Moravec
Modified: 2018-12-06 17:29 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 1144593 None None None Never

Description Pavel Moravec 2014-07-28 08:43:13 UTC
Description of problem:
Having an AMQP 1.0 client, its QMF connection statistics listed below are not updated:

framesFromClient
framesToClient
bytesFromClient
bytesToClient


Version-Release number of selected component (if applicable):
qpid-cpp-server-0.22-44


How reproducible:
100%


Steps to Reproduce:
1. in 1st terminal, run qpid-tool
2. in some other terminal, run:
qpid-send -a "q; {create:always}" -m10 --content-size=10 --connection-options "{protocol:amqp1.0}"
qpid-receive -a "q; {create:always}" -m10 --connection-options "{protocol:amqp1.0}"
3. in qpid-tool. "list connection" and then "show X" where X is the ID of either of two deleted connections


Actual results:
All above mentioned statistics are zero.


Expected results:
Relevant stats should be updated (at least *FromClient for qpid-send and *ToClient for qpid-receive connection)


Additional info:
It works well for 0-10, just 1.0 does not call "cStats->framesFromClient += 1;" or so.

Comment 1 Gordon Sim 2014-07-28 10:09:26 UTC
The bytes to/from the client are easy enough to add. The frames are a little harder since it is actually the proton library that decodes those and doesn't expose that information directly. It could certainly be done there as well, but I wonder how useful those stats are in practice. If you have message and byte counts, would that be sufficient?

Comment 2 Pavel Moravec 2014-07-28 10:24:40 UTC
(In reply to Gordon Sim from comment #1)
> The bytes to/from the client are easy enough to add. The frames are a little
> harder since it is actually the proton library that decodes those and
> doesn't expose that information directly. It could certainly be done there
> as well, but I wonder how useful those stats are in practice. If you have
> message and byte counts, would that be sufficient?

I think so; frame counts is in my opinion little bit artificial counter and I am not aware of an user interested in those values.

Maybe just worth mentioning in management-schema.xml this limitation.

Comment 3 Ted Ross 2014-07-28 12:32:03 UTC
(In reply to Gordon Sim from comment #1)
> The bytes to/from the client are easy enough to add. The frames are a little
> harder since it is actually the proton library that decodes those and
> doesn't expose that information directly. It could certainly be done there
> as well, but I wonder how useful those stats are in practice. If you have
> message and byte counts, would that be sufficient?

Yes, I think so.  As I recall, we used frames because it was very difficult to count messages at the connection level.  It was always preferable to count messages.

Comment 4 Gordon Sim 2014-07-28 15:34:06 UTC
(In reply to Gordon Sim from comment #1)
> The bytes to/from the client are easy enough to add. The frames are a little
> harder since it is actually the proton library that decodes those and
> doesn't expose that information directly.

Actually that is no longer true. Frame counts in both directions are available for the transport so the fix should be simple.


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