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

AES makes Streaming unhappy

Agile BoardAttach filesAttach ScreenshotBulk Copy AttachmentsBulk Move AttachmentsVotersWatch issueWatchersCreate sub-taskConvert to sub-taskMoveLinkCloneLabelsUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments


    • Bug
    • Status: Resolved
    • Urgent
    • Resolution: Fixed
    • 0.6.3, 0.7 beta 1
    • None
    • None
    • Critical


      Streaming service assumes there will only be one stream from S to T at a time for any nodes S and T. For the original purpose of node movement, this was a reasonable assumption (any node T can only perform one move at a time) but AES throws off streaming tasks much more frequently than that given the right conditions, which will de-sync the fragile file ordering that Streaming assumes (that T knows which files S is going to send, in what order). Eventually T is expecting file F1 but S sends a smaller file F2, leading to an infinite loop on T while it waits for F1 to finish, and T waits for S to acknowledge F2, which it never will.

      For 0.6 maybe the best solution is for AES to manually wait for one of its streaming tasks to finish, before it allows itself to create another. For 0.7 it would be nice to make Streaming more robust. The whole 4-stage-ack process seems very fragile, and poking around in parent objects via inetaddress keys makes reasoning about small pieces impossible b/c of encapsulation violations.


        1. aes.txt
          34 kB
          Edward Capriolo
        2. 1169-2.txt
          2 kB
          Gary Dusbabek
        3. 1169.txt
          2 kB
          Gary Dusbabek


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


            gdusbabek Gary Dusbabek Assign to me
            jbellis Jonathan Ellis
            Gary Dusbabek
            0 Vote for this issue
            5 Start watching this issue




                Issue deployment