[
https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13448511#comment-13448511
]
paul cannon commented on CASSANDRA-4480:
----------------------------------------
I don't think Jonathan cares much, and although I still don't like the mode
separation, I'd rather have this committed sooner than later, and I don't want
to take up your time, so let's just go with it.
So the other minor things I've seen with this patch are:
* The doc implies that the "status_change", "topology_change", "new_node",
"up", etc strings are lowercase, but they're sent in uppercase. We should
probably document that the case could be upper, or that they could be in either
case, or change to sending lowercase.
* In my tests using ccm (with a subsequent ccm add), the STATUS_CHANGE - UP
event notification appears to be sent twice. Probably it doesn't matter for any
practical purpose, but I mention it in case it's indicative of a bug.
* This probably isn't isolated to this change, but I noticed it here: when
something results in an error message on the native protocol, the resulting
error message does not have a matching stream-id for the corresponding request.
Makes it hard to send back to the right place.
> 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
