Hi, I want to bring up some important changes to how addresses should be handled in Cassandra after 7544. As of 7544 a Cassandra instance (sometimes referred to as a node in the code) can't be identified by an InetAddress. It can't be identified for the purposes of the internal storage communication, and also for the purpose of the client port used for CQL.
InetAddressAndPort is the class we are using and that is almost always a reference to the storage port and it will supply the port from the yaml file if none is provided/available. InetSocketAddress is the type we used to refer to the native protocol address in most places as well as to interface with outside libraries like Netty or Java when opening connections although there are are few places where it is an InetAddressAndPort so you will need to look for variables named rpc address, or native address to know. Using just an InetAddress for comparison is almost always wrong. Unwrapping the address from an InetAddressAndPort is almost always wrong. If you find a comparison where one side is an InetAddressAndPort and the other is an InetAddress it's a bug and there is probably a port available for you construct an InetAddressAndPort. In limited circumstances there might not be a port available such as when talking to a prior version node during rolling upgrade in which case you can let InetAddressAndPort supply the default from the YAML. In FBUtilities you should pretty much never use getJustLocalAddress(), getJustBroadcastAddress() or getJustBroadcastNativeAddress(). You want the AndPort version as that will have the port specific to the instance. I created https://issues.apache.org/jira/browse/CASSANDRA-14226 to add more documentation to the code to cover this a little better. Regards, Ariel --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
