Red Hat Bugzilla – Bug 813742
queue replication fails when org.apache.qpid.example.Spout is used
Last modified: 2014-11-09 17:38:38 EST
Description of problem: Generating messages via Java client and org.apache.qpid.example.Spout program to a queue that is replicated to another broker fails. Curiously, doing so via C++ spout, no issue appears. Version-Release number of selected component (if applicable): qpid-java client 0.10 + (qpid 0.12 and/or qpid 0.14-12) How reproducible: 100% Steps to Reproduce: 1. Setup queue state replication e.g. as per https://cwiki.apache.org/qpid/queue-state-replication.html (see Example there) 2. on source broker, send some messages to the queue-a queue: cd /usr/share/doc/qpid-java-0.10/examples ./run_example.sh org.apache.qpid.example.Spout -c 10 queue-a 3. Check on destination broker if the messages were replicated there Actual results: Destination broker does not get the messages. Instead, the federation link is disconnected with error log: 2012-04-18 08:46:30 error Connection 10.34.1.187:5672-10.34.1.197:49434 closed by error: Unexpected command continuation frame. (qpid/SessionState.cpp:68)(501) Expected results: Replication of the messages works, no problems on the federation link. Additional info: (*) the problem is triggered by processing a message in replication-queue to be sent via federation link - as the error appears only after sending messages to the source broker queue (*) sending messages via C++ client works properly, the diff in sent messages is: Java: 2012-04-18 11:24:58 trace RECV [127.0.0.1:5672-127.0.0.1:51796]: Frame[be; channel=0; header (85 bytes); properties={{MessageProperties: content-length=0; message-id=4c0a7290-27d6-382c-b1a0-73ec0b046a3b; content-type=text/plain; content-encoding=UTF-8; user-id=guest; }{DeliveryProperties: priority=4; delivery-mode=2; timestamp=1334741098140; exchange=; routing-key=testQueue; }}] C++: 2012-04-18 11:25:49 trace RECV [127.0.0.1:5672-127.0.0.1:51801]: Frame[Ebe; channel=1; header (98 bytes); properties={{MessageProperties: content-length=0; correlation-id=; content-type=; user-id=; application-headers={spout-id:V2:38:vbin16(fc5d83c3-b844-40f1-a43c-3dbf29ff601c:0)}; }{DeliveryProperties: priority=1; routing-key=testQueue; }}]
Fixed upstream: http://svn.apache.org/viewvc?rev=1327515&view=rev
Also requires: http://svn.apache.org/viewvc?rev=1327596&view=rev for build on windows.
Tested on RHEL5.8 and RHEL6.3 (both i386 and x86_64). The scenario from comment 0 works fine now with java clients. Packages used for testing: RHEL5 python-qpid-0.18-2.el5 python-qpid-qmf-0.18-2.el5 qpid-cpp-client-0.18-2.el5 qpid-cpp-client-devel-0.18-2.el5 qpid-cpp-client-devel-docs-0.18-2.el5 qpid-cpp-client-ssl-0.18-2.el5 qpid-cpp-server-0.18-2.el5 qpid-cpp-server-cluster-0.18-2.el5 qpid-cpp-server-devel-0.18-2.el5 qpid-cpp-server-ssl-0.18-2.el5 qpid-cpp-server-store-0.18-2.el5 qpid-cpp-server-xml-0.18-2.el5 qpid-java-client-0.18-3.el5 qpid-java-common-0.18-3.el5 qpid-java-example-0.18-3.el5 qpid-qmf-0.18-2.el5 qpid-qmf-devel-0.18-2.el5 qpid-tools-0.18-2.el5 RHEL6 python-qpid-0.18-2.el6_3 python-qpid-qmf-0.18-2.el6_3 qpid-cpp-client-0.18-2.el6_3 qpid-cpp-client-devel-0.18-2.el6_3 qpid-cpp-client-devel-docs-0.18-2.el6_3 qpid-cpp-server-0.18-2.el6_3 qpid-cpp-server-devel-0.18-2.el6_3 qpid-cpp-server-store-0.18-2.el6_3 qpid-cpp-server-xml-0.18-2.el6_3 qpid-java-client-0.18-3.el6 qpid-java-common-0.18-3.el6 qpid-java-example-0.18-3.el6 qpid-qmf-0.18-2.el6_3 qpid-tools-0.18-2.el6_3 -> 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/RHSA-2013-0561.html