Bug 473236

Summary: 'Failed: Timed out waiting for broker to synchronize' issue (when qpidd run with switch --default-queue-limit)
Product: Red Hat Enterprise MRG Reporter: Frantisek Reznicek <freznice>
Component: qpid-cppAssignee: messaging-bugs <messaging-bugs>
Status: NEW --- QA Contact: Kim van der Riet <kim.vdriet>
Severity: low Docs Contact:
Priority: medium    
Version: 1.1CC: gsim
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Frantisek Reznicek 2008-11-27 10:10:13 UTC
'Failed: Timed out waiting for broker to synchronize' issue (when qpidd run with switch --default-queue-limit)

Description of problem:

Command 'qpid-config add queue test-queue' fails when in touch with qpidd configured by --default-queue-limit switch.
Commands returns message: 'Failed: Timed out waiting for broker to synchronize'
and exits with error code 1.
qpidd started for this case like 'qpidd --auth no --log-enable info+ --default-queue-limit 1000 --data-dir data2'

When qpidd started as daemon using 'service' above mentioned qpid-config command passes (no --default-queue-limit switch).

Issue observed on both RHEL 5.2 (x86_64) and 4.7 (i386/x86_64)

As soon as '--default-queue-limit 1000' switch is removed qpid-config works as expected.

Triggered by qpid_java_exceptions_bz459130 test.


Version-Release number of selected component (if applicable):
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# rpm -qa | egrep '(qpid|rhm)'
qpidc-rdma-0.3.719671-1.el5
rhm-docs-0.3.719580-3.el5
qpidc-0.3.719671-1.el5
qpidd-devel-0.3.719671-1.el5
python-qpid-0.3.719419-2.el5
qpidd-acl-0.3.719671-1.el5
qpidc-devel-0.3.719671-1.el5
qpidd-rdma-0.3.719671-1.el5
qpid-java-client-0.3.712662-1.el5
qpidd-0.3.719671-1.el5
qpidd-ssl-0.3.719671-1.el5
qpidd-xml-0.3.719671-1.el5
rhm-0.3.2804-4.el5
qpidc-perftest-0.3.719671-1.el5
qpid-java-common-0.3.712662-1.el5
qpidc-ssl-0.3.719671-1.el5
qpidd-cluster-0.3.719671-1.el5

How reproducible:
100% on above mentioned packages


Steps to Reproduce:
0. install above mentioned packages
1. follow the detailed transcript:

Deatiled transcript:

[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# mkdir data2
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# qpidd --auth no --log-enable info+ --default-queue-limit 1000 --data-dir data2 >qpidd.log 2>&1 &
[1] 24220
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]#
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]#
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# service qpidd status
qpidd (pid 24220) is running...
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# qpid-config add queue test-queue
Failed: Timed out waiting for broker to synchronize
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# echo $?
1
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# kill -2 %1
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]#
[1]+  Done                    qpidd --auth no --log-enable info+ --default-queue-limit 1000 --data-dir data2 > qpidd.log 2>&1
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# service qpidd status
qpidd is stopped
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# service qpidd start
Starting Qpid AMQP daemon:                                 [  OK  ]
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# qpid-config add queue test-queue
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# echo $?
0
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# service qpidd status
qpidd (pid 24319) is running...
[root@dhcp-lab-200 qpid_java_exceptions_bz459130]# service qpidd stop
Stopping Qpid AMQP daemon:                                 [  OK  ]



Actual results:
see above -> Failed: Timed out waiting for broker to synchronize issue

Expected results:
no issue is expected

Comment 1 Gordon Sim 2008-11-27 10:56:36 UTC
Most likely due to the management queues needing a max depth greater than 1000 bytes for operation. Can we verify the limit at which the error appears?

Comment 2 Gordon Sim 2008-11-27 11:12:23 UTC
Frantisek verified correct operation with max depth of 10k bytes. Ted, can you work out a theoretically minimum allowed queue depth for correct operation of the management system? Maybe we should add a release note to communicate that?

I'm targetting this for the next release as I feel there is a simple workaround and the impact of this is therefore minimal. However we perhaps want to consider whether management queues should set their own depths or some other way of handling this a bit more gracefully.