[
https://issues.apache.org/jira/browse/CASSANDRA-4480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13447188#comment-13447188
]
Sylvain Lebresne commented on CASSANDRA-4480:
---------------------------------------------
As said, the goal is mostly a way to make it extra clear that registering for
events on very connection is a bad idea. And somewhat protect users against
defective clients that does register on all connections.
It may not be the end of the world if you do do it, but on largish clusters
with a largish number of clients, this is still quite a bit of
useless/duplicate messages, and this for no benefits whatsoever (at least none
I can think of). Also, and while I'll admit this is more opinionated, I think
that having a (or a small number of) dedicated connection for events is likely
the saner way to handle this for a client library.
All this to say that I do think that it is worth making it as clear as we can
that events are intended *not* to be set on every connections. Now granted
documenting it could be considered good enough, but I kind of like the idea of
making it harder for client implementers to do the wrong thing (aka "people
don't like reading docs"). And the data/control mode don't seem like much
complication to me (in particular I've made it so that client library that
don't want to suppport events just yet don't have to do anything).
That being said, if everyone else prefers removing the two modes, I don't mind
too much.
> 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
