Cause: Federated link Id numbers are assigned sequentially from a list of 64k candidates. After 64k link numbers have been assigned then the number sequence starts again at zero and link Id number collisions occur.
Consequence: Federated links receive errors when trying to create sessions using duplicated Id numbers.
Fix: Keep a list of in-use link Id numbers and do not use that would conflict with existing links.
Result: Federated links may be created and destroyed indefinitely without receiving errors.
Description of problem:
Link does not properly track available channel numbers for the connection, instead it uses a counter which wraps at 64K. Therefore, if you create and delete enough bridges so that the counter wraps, you will encounter a channel collision between two bridges.
Oct 19 17:35:31 system-node1a-cluster qpidd[22883]: 2012-10-19 17:35:31 [Protocol] error Channel exception: transport-busy: Channel 1 already attached to anonymous.qpid.bridge_session_qpid.broker-replicator.bridge.da11c440-d009-4f00-800b-27f04a820cee_eb35657f-6bc9-4f9d-b871-8ccfe640953f (qpid/amqp_0_10/SessionHandler.cpp:159)
Oct 19 17:35:31 system-node1a-cluster qpidd[22883]: 2012-10-19 17:35:31 [Protocol] error Execution exception: invalid-argument: session.detach: incorrect session name: qpid.bridge_session_qpid.replicator-TDQ.l.RRAA.RRAA+2870.amqp1.a908ab6b-2465-4d7c-a4e8-954ccf94223d_9f539e38-b017-4131-82fb-4c135144378f, expecting: qpid.bridge_session_qpid.replicator-Bridge.b.RRAA.968e1e94-fe04-4488-a411-2ddd2e53cefc_9f539e38-b017-4131-82fb-4c135144378f (qpid/amqp_0_10/SessionHandler.cpp:183)
Version-Release number of selected component (if applicable):
Qpid 0.18
How reproducible:
100%
Steps to Reproduce:
1. Create a federated link between two brokers
2. Create 1 bridge and then create/delete ~64K additional bridges
Actual results:
The channel counter in Link will eventually wrap and cause a collision with the first bridge even though plenty of channels are available
Expected results:
New bridges will be assigned unique channel numbers
Additional info:
This was tested on RHEL5.9 and RHEL6.3 (both i386 and x86_64). This issue has been fixed.
Packages used for testing:
RHEL5.9
python-qpid-0.18-4.el5
python-qpid-qmf-0.18-9.el5
qpid-cpp-client-0.18-10.el5
qpid-cpp-client-devel-0.18-10.el5
qpid-cpp-server-0.18-10.el5
qpid-cpp-server-devel-0.18-10.el5
qpid-qmf-0.18-9.el5
qpid-tools-0.18-7.el5
RHEL6.3
python-qpid-0.18-4.el6
python-qpid-qmf-0.18-9.el6_3
qpid-cpp-client-0.18-10.el6_3
qpid-cpp-client-devel-0.18-10.el6_3
qpid-cpp-server-0.18-10.el6_3
qpid-cpp-server-devel-0.18-10.el6_3
qpid-qmf-0.18-9.el6_3
qpid-tools-0.18-7.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