[ 
https://issues.apache.org/jira/browse/CASSANDRA-5400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623855#comment-13623855
 ] 

Carl Yeksigian commented on CASSANDRA-5400:
-------------------------------------------

For us, this is definitely something that would be useful. It would be better 
to have our fat clients using the same name. We are currently using virtual IP 
addresses, and while it works, it seems like a workaround, and this patch is 
meant to fix the workaround. We have to be careful to refer to the correct IP 
addresses, which has already caused us problems with hints being replayed to 
the fat client because we reversed the IP addresses in some of the 
configurations. While this is a large change, I do think that it is justified, 
but I do understand that the benefits may be minimal for a lot of users; I'm 
biased because it does solve our issues.

Assuming that we agree that we should support multi-port clusters, I think that 
there are a few changes that are necessary to make this work. Also, rather than 
continually posting 600k patches, I'm going to work on this on a git branch 
instead (https://github.com/carlyeks/cassandra/tree/cie).

1. multi-port should be a new mode, not a default operation. Updated clients 
can talk to the multi-port hosts, but the defaults would be that all of the 
hosts use the same port to communicate with.
2. If the multi-port mode is enabled, then the peers table will be altered in 
some way. Maybe we can drop the peers table (copying the data into memory, only 
used for the upgrade), and create a new peers table that uses (address, port) 
as the primary key.
3. Internally, Cassandra can switch to using the endpoint, since the serializer 
will use the CompactEndpointSerializer for prior messaging service versions.
4. We have to gossip the RPC endpoint (so, this issue will be blocked by 
CASSANDRA-4501).
                
> Allow multiple ports to gossip from a single IP address
> -------------------------------------------------------
>
>                 Key: CASSANDRA-5400
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5400
>             Project: Cassandra
>          Issue Type: New Feature
>    Affects Versions: 2.0
>            Reporter: Carl Yeksigian
>            Assignee: Carl Yeksigian
>             Fix For: 2.0
>
>         Attachments: 5400.txt, 5400-v2.txt, 5400-v3.patch, 5400-v4.patch
>
>
> If a fat client is running on the same machine as a Cassandra node, the fat 
> client must be allocated a new IP address. However, since the node is now a 
> part of the gossip, the other nodes in the ring must be able to talk to it. 
> This means that a local only address (127.0.0.n) won't actually work for the 
> rest of the ring.
> This also would allow for multiple Cassandra service instances to run on a 
> single machine, or from a group of machines behind a NAT.
> The change is simple in concept: instead of using an InetAddress, use a 
> different class. Instead of using an InetSocketAddress, which would still tie 
> us to using InetAddress, I've added a new class, "CassandraInstanceEndpoint". 
> The serializer allows for reading a serialized Inet4Address or Inet6Address; 
> also, the message service can still communicate with 
> non-CassandraInstanceEndpoint aware code.

--
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: http://www.atlassian.com/software/jira

Reply via email to