cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Burroughs (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-5899) Sends all interface in native protocol notification when rpc_address=
Date Fri, 13 Dec 2013 13:28:07 GMT


Chris Burroughs commented on CASSANDRA-5899:

So I don't think this is terribly uncommon, but as an example all of our nodes have two interfaces.
 Depending on where a client is in the network there are 3 address (interfaces + one is NATed
for inter-DC) that could potential work, but only 1-2 that would work.  Some might appear
to work but would be very bad (go out the local net and back in or something).  I am unsure
how any single value for broadcast_rpc_address would be useful, nor how even a list could
work since which to choose is client location dependent.

> Sends all interface in native protocol notification when rpc_address=
> ----------------------------------------------------------------------------
>                 Key: CASSANDRA-5899
>                 URL:
>             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= 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 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

View raw message