Bug 612451 - Node of cluster crash when replication is used
Summary: Node of cluster crash when replication is used
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
(Show other bugs)
Version: beta
Hardware: All Linux
medium
medium
Target Milestone: 1.3
: ---
Assignee: messaging-bugs
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-08 09:17 UTC by Jiri Kolar
Modified: 2010-07-09 11:40 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-09 11:40:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
needed for qc_sender (51.65 KB, text/x-python)
2010-07-08 09:18 UTC, Jiri Kolar
no flags Details
sender client (790 bytes, text/x-python)
2010-07-08 09:18 UTC, Jiri Kolar
no flags Details
test case (1.91 KB, text/x-sh)
2010-07-08 09:19 UTC, Jiri Kolar
no flags Details

Description Jiri Kolar 2010-07-08 09:17:13 UTC
Description of problem:
When we create two node cluster and use replication on one of those nodes. Second cluster node crash once messages are send to replication queue.

Version-Release number of selected component (if applicable):
qpid-cpp-server-ssl-0.7.946106-6
qpid-cpp-server-cluster-0.7.946106-6
qpid-cpp-server-0.7.946106-6

How reproducible:
always

Steps to Reproduce:

1.Start first cluster node with auth and replication

qpidd --auth yes --data-dir /tmp/1 --cluster-name na1m-dev1  --log-enable info+ --replication-queue EVENT_QUEUE --create-replication-queue &

2.Create queue and exchange and bind
qpid-config --broker-addr localhost add queue QUEUE --generate-queue-events 1
qpid-config add exchange direct EXCHANGE
qpid-config bind EXCHANGE QUEUE KEY

3.Start second node

qpidd -p 5673 --auth yes --data-dir /tmp/2 --cluster-name na1m-dev1 --log-enable info+ &

4.Start standalone broker
qpidd -p 5674 --auth yes --data-dir /tmp/3 --log-enable info+ &

5.Estabilish replication

qpid-config --broker-addr localhost:5674 add exchange replication replication-exchange
qpid-config --broker-addr localhost:5674 add queue QUEUE        
qpid-route --ack 2 queue add localhost:5674 localhost:5672 replication-exchange EVENT_QUEUE

6. Send messages to first cluster node (I used our sender client , but it will probably work with usual sender as well)

qc_sender.py -u guest --password=guest -e EXCHANGE -r KEY --send-gen-msg-cnt=5

(sender client attached)

I attach my .sh script that i used to reproduce this issue (you might have to adjust paths) as well as sender client
Actual results:
Second node of cluster crash with message:

error Execution exception: invalid-argument: anonymous@QPID.8d408e31-532e-4d9c-9888-cb9fce56e05d: confirmed < (3+0) but only sent < (0+0) (qpid/SessionState.cpp:151)
2010-07-07 12:09:33 critical cluster(10.16.64.144:30397 READY/error) local error 897 did not occur on member 10.16.64.144:30356: invalid-argument: anonymous@QPID.8d408e31-532e-4d9c-9888-cb9fce56e05d: confirmed < (3+0) but only sent < (0+0) (qpid/SessionState.cpp:151)
2010-07-07 12:09:33 critical Error delivering frames: local error did not occur on all cluster members : invalid-argument: anonymous@QPID.8d408e31-532e-4d9c-9888-cb9fce56e05d: confirmed < (3+0) but only sent < (0+0) (qpid/SessionState.cpp:151) (qpid/cluster/ErrorCheck.cpp:89)
2010-07-07 12:09:33 notice cluster(10.16.64.144:30397 LEFT/error) leaving cluster na1m-dev1
2010-07-07 12:09:33 notice Shut down


Expected results:
node should not crash

Additional info:

Comment 1 Jiri Kolar 2010-07-08 09:18:27 UTC
Created attachment 430277 [details]
needed for qc_sender

Comment 2 Jiri Kolar 2010-07-08 09:18:59 UTC
Created attachment 430278 [details]
sender client

Comment 3 Jiri Kolar 2010-07-08 09:19:30 UTC
Created attachment 430279 [details]
test case

Comment 4 Gordon Sim 2010-07-09 11:40:44 UTC
The --replication-queue and --create-replication-queue options need to be specified to the second node (in step 3 above). With that in place this works as expected.


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