This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 868403 - Channel collision on federated link after creating/deleting ~64K bridges
Channel collision on federated link after creating/deleting ~64K bridges
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Unspecified Unspecified
high Severity unspecified
: 2.3
: ---
Assigned To: Chuck Rolke
Leonid Zhaldybin
: Patch
Depends On:
Blocks: 698367
  Show dependency treegraph
Reported: 2012-10-19 14:16 EDT by Jason Dillaman
Modified: 2014-11-09 17:38 EST (History)
4 users (show)

See Also:
Fixed In Version: qpid-cpp-0.18-4
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Last Closed: 2013-03-06 13:52:22 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:

Attachments (Terms of Use)
Quick patch to keep track of available channels (3.08 KB, patch)
2012-10-19 15:40 EDT, Jason Dillaman
no flags Details | Diff

  None (edit)
Description Jason Dillaman 2012-10-19 14:16:37 EDT
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 (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:

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:
Comment 2 Jason Dillaman 2012-10-19 15:40:36 EDT
Created attachment 630232 [details]
Quick patch to keep track of available channels
Comment 3 Chuck Rolke 2012-10-25 10:27:27 EDT
Fixed upstream at commit 1402158.

Fix is not exactly as proposed but should do the job. See
Comment 6 Leonid Zhaldybin 2012-11-25 12:45:03 EST
This was tested on RHEL5.9 and RHEL6.3 (both i386 and x86_64). This issue has been fixed.

Packages used for testing:



Comment 8 errata-xmlrpc 2013-03-06 13:52:22 EST
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.

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