[ https://issues.apache.org/jira/browse/CASSANDRA-13459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434431#comment-16434431 ]
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. > {{DIAGNOSTIC_EVENT(GossiperEvent, MAJOR_STATE_CHANGE_HANDLED)}}. This still > has to be worked out and I'd appreciate any feedback. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org