[
https://issues.apache.org/jira/browse/CASSANDRA-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12878232#action_12878232
]
albert_e edited comment on CASSANDRA-1169 at 6/12/10 4:35 AM:
--------------------------------------------------------------
StreamOutManager.waitForStreamCompletion() can't block the AES streaming thread
if StreamOutManager has not been removed from streamManagers map and
StreamOutManager.condition is signaled once.
Make StreamOutManager.addFilesToStream() synchronized and block the thread if
StreamOutManager.files.size() > 0 may be more efficient.
was (Author: albert_e):
StreamOutManager.waitForStreamCompletion() can't block the AES streaming
thread if StreamOutManager has not been removed from streamManagers map.
Make StreamOutManager.addFilesToStream() synchronized and block the thread if
StreamOutManager.files.size() > 0 may be more efficient.
> AES makes Streaming unhappy
> ---------------------------
>
> Key: CASSANDRA-1169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1169
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Assignee: Gary Dusbabek
> Priority: Critical
> Fix For: 0.6.3, 0.7
>
> Attachments: 1169.txt, aes.txt
>
>
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
