cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-9429) Trace Complete Push Notification - questioning concept
Date Tue, 19 May 2015 17:58:01 GMT

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

Tyler Hobbs commented on CASSANDRA-9429:
----------------------------------------

The fact that drivers will end up having to poll anyway due to replication lag is the biggest
argument for reverting this, IMO.  The primary motivation was simplifying driver logic and
maybe reducing the number of queries, but unfortunately it looks like neither of those will
really happen.  The benefit we're left with is pretty small, and not worth the additional
server and driver-side complexity.

> Trace Complete Push Notification - questioning concept
> ------------------------------------------------------
>
>                 Key: CASSANDRA-9429
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9429
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Adam Holmberg
>            Priority: Minor
>             Fix For: 2.2.0 rc1
>
>
> 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.4#6332)

Mime
View raw message