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.
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.
Note: both management IDs AND LinkRegistry keys need the transport prefix. Changed severity to high as this can cause a cluster crash.
Alan, supposing the old cluster code and not ha, is this still true?
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