Bug 705833

Summary: Management identifiers for local connections may not be unique across a clustered broker
Product: Red Hat Enterprise MRG Reporter: Andrew Stitcher <astitcher>
Component: qpid-cppAssignee: messaging-bugs <messaging-bugs>
Status: NEW --- QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: unspecified Docs Contact:
Priority: low    
Version: 2.0CC: jross
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:

Description Andrew Stitcher 2011-05-18 16:12:46 UTC
Description of problem:

If you have a cluster with brokers on different machines then there is nothing to stop multiple local connections ending up with the same connection identifier. Although the identifier would be the same the connections would refer to different connections on different machines/brokers.

For example you could have a connection with the identifier
"127.0.0.1:5672-127.0.0.1:45309" on 2 different clustered brokers each referring to a different local connection.

This issue would apply to any local connection protocol, so when we implement unix domain sockets we would be prey to the same issue. In fact it would be made worse becuase unix domain sockets have anonymous peer addresses and so the management connection identifier has to be constructed to refer to the connection and using an identical algorithm on different nodes will guarantee that you would get identical connections identifiers.

How reproducible:

Hard to say, it doesn't seem to have been reported in "real deployment".
But for any given pair of local connections the collision probability is less than 1 in 4 billion. However this probability will drop significantly as more connections are involved. Also the probability may be lower if the algorithm for choosing the connecting port number is correlated across the machines (it seems to me that is very likely true)