[ 
https://issues.apache.org/jira/browse/CASSANDRA-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930024#comment-15930024
 ] 

Stefan Podkowinski commented on CASSANDRA-9429:
-----------------------------------------------

Sorry to necro this ticket, but [~snazy], do you mind to ninja TRACE_COMPLETE 
from the Event.Type list?
https://github.com/apache/cassandra/search?utf8=%E2%9C%93&q=TRACE_COMPLETE
Took me a while to figure out why it's unreferenced.

> Revert CASSANDRA-7807 (tracing completion client notifications)
> ---------------------------------------------------------------
>
>                 Key: CASSANDRA-9429
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9429
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Adam Holmberg
>            Assignee: Robert Stupp
>            Priority: Minor
>             Fix For: 2.2.0 rc1
>
>         Attachments: 9429.txt
>
>
> Follow-on to CASSANDRA-7807, where I opened a discussion without realizing 
> the version was released:
> I know I'm late to this ticket, but as I began to integrate this feature for 
> the Python driver, I developed some reservations about its usefulness. I 
> understand the original intent to avoid polling and eventually simplify trace 
> handling. However, it introduces some complexity supporting multiple protocol 
> versions, and I'm not sure it will even avoid the need for polling, due to 
> replication lag.
> Here are some of the things required to take advantage:
> - Extra registration overhead per connection, or dynamically register on 
> first trace
> - Extra book-keeping – trace ID per connection
> - New modes of failure (polling is resilient as the cluster)
> - Event may arrive before trace data is replicated
> - Drivers must still implement polling following event, and for lesser 
> protocol versions
> Given the above, I'm not sure it's worth it to implement to save a few 
> polling round-trips, especially when it's only client-initiated traces (which 
> will typically not be in a hot path).
> I'm open to discussion on the matter.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to