Ariel Weisberg commented on CASSANDRA-13459:

One of the differences between other events and diagnostic events is that other 
events are relatively infrequent so we might have been fine until now with not 
implementing proper backpressure. I checked quickly and I didn't see what 
looked like backpressure for clients Looking at some of the events like gossip 
or hints it seems like it's going to be a steady stream all the time.

Most messages sent to clients are responses to requests and if the client can't 
communicate with the server it won't be sending a new requests so it's a self 
limiting problem except for the less common cases where communication fails in 
one direction. I think that may be why we have gotten away without proper 
backpressure until now. It's also possible that there is a hidden bit of code 
somewhere that disables read on a client if we can't write.

bq. We could specify a subscription mechanism for native transport that is not 
specific to diag events. But what would the subject look like to subscribe to?

Looking at what you have now there is no query language correct? You subscribe 
to these events via the wire protocol not the query language? 

Devil's advocate we could have a flat namepsace of events to subscribe to 
subscribe to right now (which is how it seems to work?). I am just saying for 
the wire protocol and internal implementation differentiate between 
subscription and debug/diagnostic. Those are two different concerns.

> 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