cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-4480) Binary protocol: adds events push
Date Wed, 05 Sep 2012 13:37:08 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sylvain Lebresne updated CASSANDRA-4480:
----------------------------------------

    Attachment: 4480-v2.txt

You got me thinking and I think I changed my mind. Those two modes probably complicate things
needlessly, especially for tools that only need one connection in the first place.

So I'm attaching v2 where I've removed it (the rest is unchanged). I've simply add a few sentences
in the doc to warn that registering on too many connection is useless.

bq. The doc implies that the "status_change", "topology_change", "new_node", "up", etc strings
are lowercase, but they're sent in uppercase

True, I've updated the doc (the code handle those case insensitively, but better be coherent
with what we return).

bq. the STATUS_CHANGE - UP event notification appears to be sent twice

I think that might be because the UP event is send on both the onAlive and onRestart gossip
events and I think they can be both triggered sometimes. Could be that we could skip the onRestart
in that case, I'll ask Brandon.

bq. 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.

That is indeed not related to this but you're right, that's a bug. I'll fix that in a separate
commit (it's a rather trivial fix).
                
> 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

Mime
View raw message