[
https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447369#comment-13447369
]
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: 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
