[
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: [email protected]
For additional commands, e-mail: [email protected]
