[
https://issues.apache.org/jira/browse/CASSANDRA-9429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15931182#comment-15931182
]
Robert Stupp commented on CASSANDRA-9429:
-----------------------------------------
I'd prefer to do this in a separate ticket. Can you provide a patch?
> 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)
