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

Sam Tunnicliffe commented on CASSANDRA-4092:
--------------------------------------------

Added a new thrift call, describe_token_distribution, which is simpler & less 
invasive than changing describe_ring. Thrift doesn't support function 
overloading, so we'd need to do something like define a new struct to wrap the 
keyspace arg and make it optional, which seemed a bit much really.
The implementation of the new call just delegates to 
StorageService.getTokenToEndpointMap() so its output will include bootstrapping 
nodes as well
as those which have fully joined the ring. I've added a test to the system 
tests which does some minimal validation of the thrift response.

First patch contains the changes to the primary source & thrift idl file, the 
second just the new java generated from the thrift file.
                
> Allow getting a simple Token->node map over thrift
> --------------------------------------------------
>
>                 Key: CASSANDRA-4092
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4092
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Nick Bailey
>             Fix For: 1.1.1
>
>         Attachments: 
> v1-0001-CASSANDRA-4092-New-thrift-call-to-get-simple-token-nod.txt, 
> v1-0002-CASSANDRA-4092-New-generated-java-following-change-to-.txt
>
>
> Right now the thrift describe_ring call is intended to be used to determine 
> ownership for a keyspace. It can also (and often is) be used by clients to 
> just get a view of what the ring looks like. Since it requires a keyspace as 
> an argument though, it can sometimes be impossible to see what the ring looks 
> like. For example, in a 2 DC/2 node ring where keyspace X exists only dc1. 
> The results of 'describe_ring X' would look something like (with tokens 0 and 
> 10):
> {noformat}
> {[0,10]: [node0], [10,0]: [node0]}
> {noformat}
> This is indicating that node0 owns everything for that keyspace since it only 
> exists in 1 datacenter. From this output though it is impossible to tell 
> which token (0 or 10) node0 owns, as well as what the other node in the 
> cluster is.
> There are two options here. 
> * Allow running describe_ring with no parameters to get a view of token->ip 
> without taking replication into consideration.
> * Add a new thrift call to achieve this.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to