Bug 594739 - LinkRegistry should use transport,host,port as key, not just host,port.
LinkRegistry should use transport,host,port as key, not just host,port.
Status: NEW
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
beta
All Linux
low Severity medium
: ---
: ---
Assigned To: mick
MRG Quality Engineering
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-21 09:27 EDT by Alan Conway
Modified: 2013-02-25 16:14 EST (History)
2 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Conway 2010-05-21 09:27:45 EDT
Description of problem:

The LinkRegistry uses (host,port) as the unique key for a connection.It should use (transport,host,port) to get a unique key. (host,port) is not guaranteed to be unique if the same port number is used by different transports on the same host. 

Version-Release number of selected component (if applicable):

r946227, 1.3 beta 2

How reproducible:

Not observed as a bug as yet, but it could cause problems on a broker with connections over multiple transports.
Comment 1 Alan Conway 2011-02-03 09:25:52 EST
As of r1066220, connection IDs and LinkRegistry keys are
  "localhost:localport-remotehost:remoteport"
So the desired key would be something like
  "transport:localhost:localport-remotehost:remoteport"

If you look at r1066220 you'll see it introduced getFullAddress() at the transport layer and uses that rather than getPeerAddress() to construct management IDs and LinkRegistry keys.

Also this comment from astitcher is relevant: 

Perhaps it would be better to remove the notion of full address from the protocol/transport code and just expose the remote/local addresses [ac: and transport] from the lower layers in such a way that the management code [ac: and LinkRegistry] can construct an appropriate ID itself.

NB. I think that these IDs aren't guaranteed to be unique even now when considered across transports. For example an RDMA full address could be identical to a TCP/SSL full address if the TCP/SSL connection is IPoIB on the same IB link.
So I suggest it might be better for the management code to prefix the transport name to the ID in any case.
Comment 2 Alan Conway 2011-02-03 10:14:17 EST
Note: both management IDs AND LinkRegistry keys need the transport prefix.

Changed severity to high as this can cause a cluster crash.
Comment 3 Justin Ross 2013-02-24 20:49:41 EST
Alan, supposing the old cluster code and not ha, is this still true?
Comment 4 Alan Conway 2013-02-25 16:05:07 EST
Even on a stand-alone broker, this might cause some issues for management, e.g. one connection hiding another, or issues with setting up Links on affected connections.

With new HA this would not cause any issue beyond those of a stand-alone broker.

In the old cluster code I believe this could cause a crash but have not observed it.

Issues can only arises if 
- you have multiple transport (e.g. tcp + rdma) AND
- the same port number is used in connections on different transports in the same broker

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