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

Jason Brown commented on CASSANDRA-11559:
-----------------------------------------

On the whole, +1 on this idea in general.

bq. if we need to wait until 4.0 ...

I'm pretty sure we need to wait until 4.0, esp. if public interfaces will 
affected. Also, depending on the scope/size of the refactor, it might be safer 
for a 4.0 release.

bq. encapsulated in a {{VirtualNode}} interface

I'd prefer a different name as "virtual node", at least to me, implies a token 
in addition to the other data points (maybe I'm wrong here). But this is early 
bikeshedding ;)

One idea to throw out, although it might be premature at this stage, is to 
switch from {{InetAddress}} to {{InetSocketAddress}}. This will open the door 
to allowing different port bindings for each peer in the cluster. In no way 
would/should that effort, in it's entirety, be part of this ticket, but since 
we starting down the path of factoring away from passing the {{InetAddress}} 
around everywhere as the node identifier, this might be a nice place to put in 
the initial groundwork.




> Enhance node representation
> ---------------------------
>
>                 Key: CASSANDRA-11559
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11559
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: Distributed Metadata
>            Reporter: Paulo Motta
>            Priority: Minor
>
> We currently represent nodes as {{InetAddress}} objects on {{TokenMetadata}}, 
> what causes difficulties when replacing a node with the same address (see 
> CASSANDRA-8523 and CASSANDRA-9244).
> Since CASSANDRA-4120 we index hosts by {{UUID}} in gossip, so I think it's 
> time to move that representation to {{TokenMetadata}}.
> I propose representing nodes as {{InetAddress, UUID}} pairs on 
> {{TokenMetadata}}, encapsulated in a {{VirtualNode}} interface, so it will 
> backward compatible with the current representation, while still allowing us 
> to enhance it in the future with additional metadata (and improved vnode 
> handling) if needed.
> This change will probably affect interfaces of internal classes like 
> {{TokenMetadata}} and {{AbstractReplicationStrategy}}, so I'd like to hear 
> from integrators and other developers if it's possible to change these 
> without major hassle or if we need to wait until 4.0.
> Besides updating {{TokenMetadata}} and {{AbstractReplicationStrategy}} (and 
> subclasses),  we will also need to replace all {{InetAddress}} uses with 
> {{VirtualNode.getEndpoint()}} calls on {{StorageService}} and related classes 
> and tests. We would probably already be able to replace some 
> {{TokenMetadata.getHostId(InetAddress endpoint)}} calls with 
> {{VirtualNode.getHostId()}}.
> While we will still be dealing with {{InetAddress}} on {{StorageService}} in 
> this initial stage, in the future I think we should pass {{VirtualNode}} 
> instances around and only translate from {{VirtualNode}} to {{InetAddress}} 
> in the network layer.
> Public interfaces like {{IEndpointSnitch}} will not be affected by this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to