cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paul cannon (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-4480) Binary protocol: adds events push
Date Mon, 03 Sep 2012 17:53:08 GMT


paul cannon commented on CASSANDRA-4480:

I do see what you mean, and it isn't especially inefficient to have lots of extra messages
in that worst case, but again, those events should be very rare (under normal production conditions,
well under one per day) and they're really small and are practically free to process.

The complexity on the client side probably wouldn't be very bad, like you say. An example
case where the extra complexity is at least noticeable is a driver which, for whatever reason,
only needs a single connection at a time to the cluster. Cqlsh, opscenter-agents, and other
"utility" type apps are possible instances where that would be the case. Before now, that
was perfectly doable, especially with the new async capabilities. Adding the requirement for
a second connection means either doubling up or abstracting the connection-maintenance code
(recognize when a connection goes down or is stalled, reconnecting to the appropriate place,
etc) and being able to handle odd error cases, like when authentication and setup succeeds
on one connection but not on the other, etc.

The main downside I see to making the change is that it would use up more of your time :),
and that would suck, so I'll leave it up to you.
> Binary protocol: adds events push 
> ----------------------------------
>                 Key: CASSANDRA-4480
>                 URL:
>             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
> 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:

View raw message