[
https://issues.apache.org/jira/browse/CASSANDRA-13459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454195#comment-16454195
]
Stefan Podkowinski commented on CASSANDRA-13459:
------------------------------------------------
We do implement some basic backpressure for inter-node communication
(CASSANDRA-8457) based on Netty's {{Channel.isWritable()}} indicator (see
{{MessageOutHandler.channelWritabilityChanged()}},
{{OutboundConnectionParams}}, {{QueuedMessage}}). And there's also
{{CoalescingStrategy}}. But I don't think we're doing any of this for native
transport. My guess would be that this kind of optimizations won't be very
effective for single connection based request/response semantics, in contrast
to the bulky async messaging for inter-node communication.
But we could still optimize native transport a bit for diag events by
implementing load shedding, as we only provide events on best effort basis, see
[5121a848|https://github.com/spodkowinski/cassandra/commit/5121a848855f35894f2fb5176d7dc46f7b2a8571].
Ideally we would then also indicate that messages have been dropped/omitted,
but we'll also have to introduce a corresponding message to the protocol spec.
{quote}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?
{quote}
Yes, exactly. I'd assume most drivers would have a hard time to support
publish/subscribe semantics in existing request/response query execution models.
> 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]
