Description of problem: If the protocol version is set to amqp1.0 in qpid-snmpd configuration file (/usr/share/snmp/qpid010.conf), the deamon does not even start. Moreover, when it is trying to connect to the broker, it apparently courses qpidd broker to crash: [root@lzhaldyb-rhel64x ~]# service qpidd start Starting Qpid AMQP daemon: [ OK ] [root@lzhaldyb-rhel64x ~]# service qpidd status qpidd (pid 5226) is running... [root@lzhaldyb-rhel64x ~]# service qpid-snmpd start Starting qpid-snmpd: [ OK ] [root@lzhaldyb-rhel64x ~]# service qpid-snmpd status qpid-snmpd dead but subsys locked [root@lzhaldyb-rhel64x ~]# service qpidd status qpidd dead but pid file exists Version-Release number of selected component (if applicable): qpid-snmpd-1.0.0-12.el6 qpid-cpp-server-0.22-14.el6 How reproducible: 100% Steps to Reproduce: 1. Turn on amqp1.0 for qpid-snmpd (add "connect { protocol: 'amqp1.0' }" to /usr/share/snmp/qpid010.conf). 2. Try to start qpid-snmpd: service qpid-snmpd start 3. Actual results: Both qpid-snmpd and qpidd crash. Expected results: The qpid-snmpd daemon is capable of communicating with broker using amqp v 1.0. Additional info:
I fixed the issue crashing the broker: https://svn.apache.org/r1525044, following which basic QMFv2 over 1.0 seems to work ok and more importantly broker doesn't crash.
Ernie, please amend this bug to describe the problem you are now addressing.
I found one further issue with QMFv2 over 1.0, namely that when the map message is also in 1.0 format (my first test sent a 1.0 message with 0-10 map encoding) the wrong content is used by the management agent. Now fixed also (https://svn.apache.org/r1526156) so perhaps worth a retest in case that resolves this issue also. I raised a new issue for the qpid-cpp side of things: https://bugzilla.redhat.com/show_bug.cgi?id=1011902.
Further information: With Gordon's fix in comment 1 the broker and qpid-snmpd no longer crash upon startup. However, the qpid-snmpd still crashes when the 1st qmf query is sent. Gordon's patch in comment 3 did not avoid the qmf2 exception that qpid-snmpd is encountering. I'll modify qpid-snmpd to catch and log the qmf exception to avoid the crash. I'll update this bz with information about the exception.
Ernie, any updates on this one?
It appears that libqmf2 is still crashing when qpid-snmpd is connected using amqp1.0 and sends a query. Here is the message log entry: Nov 14 10:42:29 mrg28 kernel: qpid-snmpd[25378]: segfault at 48 ip 00007f3bbfc8b2de sp 00007fff295ca1e0 error 4 in libqmf2.so.1.2.0[7f3bbfc6c000+74000] rpm -qa | grep qpid qpid-cpp-client-devel-0.22-25.el6.x86_64 qpid-cpp-client-0.22-25.el6.x86_64 qpid-cpp-server-0.22-25.el6.x86_64 qpid-qmf-0.22-22.el6.x86_64 qpid-proton-c-0.5-8.el6.x86_64 qpid-snmpd-1.0.0-14.el6.x86_64 qpid-qmf-devel-0.22-22.el6.x86_64 The only thing qpid-snmpd can do at this point is to explicity prevent protocol: 'amqp1.0' from being used in the broker connection parameters.
Okay, Ernie, let's disable amqp1.0 broker connections in qpid-snmpd. (In reply to Ernie from comment #6) > It appears that libqmf2 is still crashing when qpid-snmpd is connected using > amqp1.0 and sends a query. > > Here is the message log entry: > Nov 14 10:42:29 mrg28 kernel: qpid-snmpd[25378]: segfault at 48 ip > 00007f3bbfc8b2de sp 00007fff295ca1e0 error 4 in > libqmf2.so.1.2.0[7f3bbfc6c000+74000] > > rpm -qa | grep qpid > qpid-cpp-client-devel-0.22-25.el6.x86_64 > qpid-cpp-client-0.22-25.el6.x86_64 > qpid-cpp-server-0.22-25.el6.x86_64 > qpid-qmf-0.22-22.el6.x86_64 > qpid-proton-c-0.5-8.el6.x86_64 > qpid-snmpd-1.0.0-14.el6.x86_64 > qpid-qmf-devel-0.22-22.el6.x86_64 > > The only thing qpid-snmpd can do at this point is to explicity prevent > protocol: 'amqp1.0' from being used in the broker connection parameters.
If amqp1.0 is in the connect string, the connect string will now be ignored. qpid-snmpd -f -M -L -DAll 2>&1 | grep "amqp1" read_config: /usr/share/snmp/qpid010.conf:12 examining: connect { protocol: 'amqp1.0' } read_config: /usr/share/snmp/qpid010.conf:12 examining: connect { protocol: 'amqp1.0' } read_config: Found a parser. Calling it: connect / { protocol: 'amqp1.0' } amqp1.0 protocol not supported. Ignoring connect string: %s : { protocol: 'amqp1.0' }trace: read_config(): read_config.c, 777: Note: qpid-snmpd will still start and run, but if the connect string contains the text "amqp1.0" then the entire connect string will be ignored and the default will be used. Checked in patch 04-Disallow-ampq1.0.patch and updated spec file on branch origin/mrg-rhel-6
Tested on RHEL6.5 (both i386 and x86_64). This issue has been fixed. Packages used for testing: python-qpid-0.22-9.el6 python-qpid-qmf-0.22-25.el6 qpid-cpp-client-0.22-30.el6 qpid-cpp-client-devel-0.22-30.el6 qpid-cpp-client-devel-docs-0.22-30.el6 qpid-cpp-client-ssl-0.22-30.el6 qpid-cpp-server-0.22-30.el6 qpid-cpp-server-devel-0.22-30.el6 qpid-cpp-server-linearstore-0.22-30.el6 qpid-cpp-server-ssl-0.22-30.el6 qpid-cpp-server-xml-0.22-30.el6 qpid-java-client-0.22-5.el6 qpid-java-common-0.22-5.el6 qpid-java-example-0.22-5.el6 qpid-jca-0.22-1.el6 qpid-jca-xarecovery-0.22-1.el6 qpid-proton-c-0.6-1.el6 qpid-qmf-0.22-25.el6 qpid-snmpd-1.0.0-15.el6 qpid-tools-0.22-7.el6 -> VERIFIED