[
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)
