cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4501) Gossip the ip and port used by the binary protocol
Date Fri, 05 Apr 2013 07:42:15 GMT


Sylvain Lebresne commented on CASSANDRA-4501:

Sorry, I realize I've been a bit carried away. I saw "cql schema definitions" and somehow
assumed we were talking of one of the schema_* table but we're not.  The peers table is a
local one, so there is no problem with backward compatibility as far as rolling upgrade are
concerned, my bad (and so using a composite PK would indeed be an option).

There is compatibility issues to consider however, and that's for clients. The peers table
is the new describe_ring|token_map of CQL3 clients that thus use it. For those, just adding
a new 'port' column (without renaming existing ones) will definitively be easier to handle
that adding a new data type.

But I have more important concerns. Multiple nodes on the same IP means also by necessity
means multiple RPC/native protocol port in the cluster too.

So far, clients assumed that 1) nodes are identified by just their ip address and 2) all nodes
were using the same port for thrift/native protocol. And I'll note that they largely had no
choice about making those assumptions because the (RPC/native protocol) ports where not really
exposed. But this issue breaks those 2 assumptions. Meaning that 1) all existing client drivers
and tools that were identifying node with just the ip addresses will have to be fixed and
2) we'd have to start gossiping the rpc port (CASSANDRA-4501) because otherwise doing node
auto-discovery properly becomes much more harder (and for instance, binary protocol notifications
*assume* that all node use the same rpc port since we don't have CASSANDRA-4501).

I'll also note that none of the describe_* thrift calls include the port currently, and there
is no easy way to return it without breaking the thrift API (of course, shoving the port in
the string currently used to return the ip address would be breaking and thus non acceptable).

So I have to ask, are we absolutely sure that this addition is worth the pretty substantial
headache it will be for most clients drivers and tools? I'm no network expert but can't one
just use multiple IP aliases if he want multiple instances on the same NIC.

To be clear, I absolutely agree that it is lame we haven't identified nodes by ip and port
from day one. But it seems to me too much trouble for little benefit to change it now.

> Gossip the ip and port used by the binary protocol
> --------------------------------------------------
>                 Key: CASSANDRA-4501
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Brandon Williams
>            Priority: Minor
>             Fix For: 2.0
> Same as we gossip the rpc_address, we should add gossipping of the native transport address
(including the port). CASSANDRA-4480 has one reason why we would want to do that.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message