[
https://issues.apache.org/jira/browse/CASSANDRA-5899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13923317#comment-13923317
]
Jason Brown commented on CASSANDRA-5899:
----------------------------------------
Took a long time to think through this one, but I think on the whole it is fine
(even the EC2MRS change).
One (minor) thing to consider, however, is that with ec2 regions, typically the
client will only want to connect to server nodes within the same region and
then on the private IP addr. Your change sets the broadcastRpcAddr to the
public IP addr in EC2MRS. This has drawbacks as then clients will need to have
ingress privs set on the new server's security group (even if it is in the same
region!) to even connect to the node. The opposite of this is using the private
IP addr for the broadcast addr, which optimizes local region communication, but
is absolutely will not work for connecting to another region. So, I suppose
something you could try is:
- assume all clients connected to a given server are only in the local region
(as the server)
- if peer server (that you will send notifications about) is in the same
region, send the private IP addr (you can find it in
ApplicationState.INTERNAL_IP, more or less)
- else send the public IP addr (broadcastRpcAddr in your patch)
I'm not sure we can make the assumption all connected clients will be in the
same region as the server (which is sending it notifications), so then the only
logical choice is to send the public IP addr to the client. The client can then
do some machinations to find out about the server for which it got the IP addr,
and then potentially switch to the private IP addr if appropriate.
All this to say, +1 as is.
> 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
>
> Attachments: 5899.txt
>
>
> 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.2#6252)
