Stefan Podkowinski commented on CASSANDRA-13459:

{quote}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 
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? 
If we want to support more powerful publish/subscribe semantics, we'd have to 
allow clients to specify event matchers in a more generic way, e.g. by using 
some kind of query language.


All auditing events for "ks" keyspace updates:
 {{SUBSCRIBE diag_events "event=AuditEvent#UPDATE(keyspace=ks)"}}

Full query replication for ks.table1:
 {{SUBSCRIBE full_query_log "keyspace=ks,table=table1"}}

Subscribe to any row updates matching a query:
 {{SUBSCRIBE cdc "select * from order_status where order_id = 1"}}

Not a big fan of language-in-language, but I'm open to discuss any options, if 
that's something we should add.
{quote}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.
The current implementation will simply write and flush any event message to the 
netty stack. Netty should use it's own event loop, but I'm not sure how 
buffering is handled in detail. Maybe we could also use the 
{{Message.Dispatcher}} instead and add even messages to the (unbounded) queue 
of items to flush. But we don't do that either for "classic" schema/topo/status 
change messages.



> 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