Hide Forgot
Description of problem: A clientConnect event is not raised to signal the creation of a new AMQP 0-10 connection and AMQP 0-10 connections do not have their authIdentity visible through management Version-Release number of selected component (if applicable): qpid-0.24/early access mrg 3.0 How reproducible: 100% Steps to Reproduce: 1. start broker 2. start qpid-printevents 3. drain -f amq.direct Actual results: There is no clientConnect event shown by qpid-printevents (just queueDeclare, bind and subscribe). Also if you then run qpid-stat -c the auth and mech fields are not populated for that connection. Expected results: See clientConnect event from qpid-printevents and qpid-stat -c shows auth as anonymous Additional info:
Fixed upstream: https://svn.apache.org/r1538754
Note: ignore mention of mech field above. The mech field is not actually set for 0-10 connections, but that is not a regression as far as I can see.
"clientConnect" event can be detected by "qpid-printevents" tool; "sasl-mechanisms" and account used for connection authentication is visible via "qpid-stat -c" in the proper fields. Verified on Rhel6-x86_64 and Rhel6-i386 on packages: qpid-java-common-0.22-5.el6.noarch qpid-cpp-server-0.22-29.el6.i686 qpid-cpp-client-devel-0.22-29.el6.i686 qpid-cpp-server-store-0.22-29.el6.i686 qpid-cpp-client-devel-docs-0.22-29.el6.noarch qpid-java-example-0.22-5.el6.noarch qpid-proton-c-0.5-9.el6.i686 python-qpid-0.22-8.el6.noarch qpid-cpp-server-devel-0.22-29.el6.i686 qpid-snmpd-1.0.0-14.el6.i686 qpid-cpp-server-xml-0.22-29.el6.i686 qpid-jca-0.22-1.el6.noarch qpid-jca-xarecovery-0.22-1.el6.noarch qpid-cpp-client-0.22-29.el6.i686 perl-qpid-0.22-7.el6.i686 python-qpid-qmf-0.22-24.el6.i686 qpid-tools-0.22-7.el6.noarch ruby-qpid-qmf-0.22-24.el6.i686 qpid-proton-c-devel-0.5-9.el6.i686 qpid-cpp-server-ssl-0.22-29.el6.i686 qpid-java-client-0.22-5.el6.noarch qpid-qmf-0.22-24.el6.i686 qpid-cpp-client-ssl-0.22-29.el6.i686 qpid-cpp-server-ha-0.22-29.el6.i686 --> VERIFIED
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. http://rhn.redhat.com/errata/RHEA-2014-1296.html