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

Jun Rao commented on CASSANDRA-197:
-----------------------------------

I am not sure if we should make client a member of the cluster and receive all 
the gossiped messages. For request routing, the client only cares about the 
event of adding/removing nodes, which is infrequent. Making client a member of 
the cluster exposes it to way too many irrelevant messages. An out-of-date 
cached ring map only affects performance, not correctness. In practice, it's 
probably good enough for each client to simply refresh its cached ring map, say 
once per hour.

As for that the client has to include the server code and config file, I don't 
think it's a big deal. The server jar is already needed for java clients today 
and a client has to be aware of the thrift port. Further, each client has to 
explicitly maintain a list of cassandra servers to connect to (RingCache 
obviates that).

It is a bit awkward to expose the getRIngMap api in thrift, since only the 
client library really needs to see it, not the actual client code. However, 
thrift seems to be the only simple way for a client to talk to the server. 
MessageService is too heavy to use just for infrequent server calls. Could we 
just document that the api is not intended for direct client usage?




> Expose ring map to client for more direct access
> ------------------------------------------------
>
>                 Key: CASSANDRA-197
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-197
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jun Rao
>            Assignee: Jun Rao
>         Attachments: issue197.patchv1
>
>
> For certain applications, it would be nice if a read is sent to a node that 
> owns the data locally. This saves an extra network hop. To do that, a client 
> will need to cache the ring map and use it to figure out the nodes owning a 
> row.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to