[
https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13444642#comment-13444642
]
paul cannon commented on CASSANDRA-4480:
----------------------------------------
I don't think I like the split of 'control' and 'data' modes. Why can't the
client library relegate the REGISTER/EVENT messages to a single connection, if
the user wants it that way? This seems like it adds needless complexity on both
sides.
In the very worst case, if we remove the restriction, a few dozen connections
get an extra ~40-byte message once per (rare) topology/node-status change when
only one would have sufficed. Is that really that much of a problem?
> Binary protocol: adds events push
> ----------------------------------
>
> Key: CASSANDRA-4480
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4480
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 1.2.0
>
> Attachments: 4480.txt
>
>
> Clients needs to know about a number of cluster changes (new/removed nodes
> typically) to function properly. With the binary protocol we could start
> pushing such events to the clients directly.
> The basic idea would be that a client would register to a number of events
> and would then receive notifications when those happened. I could at least
> the following events be useful to clients:
> * Addition and removal of nodes
> * Schema changes (otherwise clients would have to pull schema all the time to
> know that say a new column has been added)
> * node up/dow events (down events might not be too useful, but up events
> could be helpful).
> The main problem I can see with that is that we want to make it clear that
> clients are supposed to register for events on only one or two of their
> connections (total, not per-host), otherwise it'll be just flooding. One
> solution to make it much more unlikely that this happen could be to
> distinguish two kinds of connections: Data and Control (could just a simple
> flag with the startup message for instance). Data connections would not allow
> registering to events and Control ones would allow it but wouldn't allow
> queries. I.e. clients would have to dedicate a connection to those events,
> but that's likely the only sane way to do it anyway.
--
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
