[ https://issues.apache.org/jira/browse/CASSANDRA-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916128#comment-13916128 ]
Tyler Hobbs commented on CASSANDRA-5899: ---------------------------------------- Sure, I'll take it. > Sends all interface in native protocol notification when rpc_address=0.0.0.0 > ---------------------------------------------------------------------------- > > Key: CASSANDRA-5899 > URL: https://issues.apache.org/jira/browse/CASSANDRA-5899 > Project: Cassandra > Issue Type: Improvement > Reporter: Sylvain Lebresne > Assignee: Tyler Hobbs > Priority: Minor > Fix For: 2.1 beta2 > > > For the native protocol notifications, when we send a new node notification, > we send the rpc_address of that new node. For this to be actually useful, > that address sent should be publicly accessible by the driver it is destined > to. > The problem is when rpc_address=0.0.0.0. Currently, we send the > listen_address, which is correct in the sense that we do are bind on it but > might not be accessible by client nodes. > In fact, one of the "good" reason to use 0.0.0.0 rpc_address would be if you > have a private network for internode communication and another for > client-server communinations, but still want to be able to issue query from > the private network for debugging. In that case, the current behavior to send > listen_address doesn't really help. > So one suggestion would be to instead send all the addresses on which the > (native protocol) server is bound to (which would still leave to the driver > the task to pick the right one, but at least it has something to pick from). > That's relatively trivial to do in practice, but it does require a minor > binary protocol break to return a list instead of just one IP, which is why > I'm tentatively marking this 2.0. Maybe we can shove that tiny change in the > final (in the protocol v2 only)? Povided we agree it's a good idea of course. > Now to be complete, for the same reasons, we would also need to store all the > addresses we are bound to in the peers table. That's also fairly simple and > the backward compatibility story is maybe a tad simpler: we could add a new > {{rpc_addresses}} column that would be a list and deprecate {{rpc_address}} > (to be removed in 2.1 for instance). -- This message was sent by Atlassian JIRA (v6.1.5#6160)