|Summary:||LinkRegistry should use transport,host,port as key, not just host,port.|
|Product:||Red Hat Enterprise MRG||Reporter:||Alan Conway <aconway>|
|Status:||NEW ---||QA Contact:||MRG Quality Engineering <mrgqe-bugs>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Alan Conway 2010-05-21 13:27:45 UTC
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 14:25:52 UTC
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 15:14:17 UTC
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-25 01:49:41 UTC
Alan, supposing the old cluster code and not ha, is this still true?
Comment 4 Alan Conway 2013-02-25 21:05:07 UTC
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