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

paul cannon commented on CASSANDRA-4480:
----------------------------------------

Okay, everything looks good at this point, except that when I stop an existing 
node and start it again, I still receive a TOPOLOGY_CHANGE - NEW_NODE event 
after the two STATUS_CHANGE - UP events, even though the up'd node was 
previously known.
                
> 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, 4480-v2.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

Reply via email to