[
https://issues.apache.org/jira/browse/CASSANDRA-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847316#comment-13847316
]
Sylvain Lebresne commented on CASSANDRA-5899:
---------------------------------------------
bq. Why don't we add an broadcast_rpc_address config option?
Good idea. I mean, I think we need it anyway for the same reasons that we have
a broadcast_listen_address, that is for when none of the interfaces on the node
are actually public to the client because there is some router in between.
The fact that we don't know which address to send when rpc_address is 0.0.0.0
is a slightly different problem, but we could make it mandatory (or strongly
recommended, but I'd personally would vote for mandatory) to set a
broadcast_rpc_address if rpc_address=0.0.0.0 and kill two birds with one stone.
> 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
> Priority: Minor
> Fix For: 2.1
>
>
> 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.4#6159)
