Uploaded image for project: 'Cassandra'
  1. Cassandra
  2. CASSANDRA-9429

Revert CASSANDRA-7807 (tracing completion client notifications)

Log workAgile BoardRank to TopRank to BottomAttach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Bug
    • Status: Resolved
    • Low
    • Resolution: Fixed
    • 2.2.0 rc1
    • None
    • None
    • Low


      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.


        Issue Links


          This comment will be Viewable by All Users Viewable by All Users


            snazy Robert Stupp Assign to me
            aholmber Adam Holmberg
            Robert Stupp
            Aleksey Yeschenko
            0 Vote for this issue
            5 Start watching this issue



              Issue deployment