Ariel Weisberg commented on CASSANDRA-13459:

So I was just thinking that forward looking restricting this mechanism to 
diagnostic events might not make sense. I was thinking a more generic 
subscription mechanism where diagnostic are events is a subset of what clients 
can conditionally subscribe to means we don't end up with naming issues in the 

For V1 of this functionality my only sticking point is that even with 1-2 
clients consuming diagnostic events we have to handle backpressure somehow. 
AFAIK we hold onto messages pending to a client for a while (indefinitely?). I 
am not actually sure what kind fo timeouts or health checks we do for clients.

All the other stuff I mentioned in CASSANDRA-12151 is not really necessary for 
V1 if it does what you need today.

> Diag. Events: Native transport integration
> ------------------------------------------
>                 Key: CASSANDRA-13459
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13459
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Stefan Podkowinski
>            Assignee: Stefan Podkowinski
>            Priority: Major
>              Labels: client-impacting
> Events should be consumable by clients that would received subscribed events 
> from the connected node. This functionality is designed to work on top of 
> native transport with minor modifications to the protocol standard (see 
> [original 
> proposal|https://docs.google.com/document/d/1uEk7KYgxjNA0ybC9fOuegHTcK3Yi0hCQN5nTp5cNFyQ/edit?usp=sharing]
>  for further considered options). First we have to add another value for 
> existing event types. Also, we have to extend the protocol a bit to be able 
> to specify a sub-class and sub-type value. E.g. 
> has to be worked out and I'd appreciate any feedback.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to