cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Updated] (CASSANDRA-5699) Streaming (2.0) can deadlock
Date Mon, 01 Jul 2013 11:06:20 GMT


Sylvain Lebresne updated CASSANDRA-5699:

    Attachment: 5699.txt

bq. Is the "stream lifecycle" documented anywhere

Yuki had written The one thing this patch changes compared
to that "design document" is that the initialization phase is slightly more complex since
we need to create 2 connection. So the first node sends a StreamInit to the other end to create
the first connection (as was done previously), but then the remote side creates a connection
back sending a StreamInit message of it's own. Then and only then do we go to the prepare

In any case, we probably want that lifecycle to be documented in the javadoc or we'll lose
track of it, so I've described this in relative detail at the head of StreamSession.

So updated the patch with those added comments and the modification to StreamRepairTask cleaned

> Streaming (2.0) can deadlock
> ----------------------------
>                 Key: CASSANDRA-5699
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Sylvain Lebresne
>            Assignee: Sylvain Lebresne
>             Fix For: 2.0 beta 1
>         Attachments: 5699.txt
> The new streaming implementation (CASSANDRA-5286) creates 2 threads per host for streaming,
one for the incoming stream and one for the outgoing one. However, both currently share the
same socket, but since we use synchronous I/O, a read can block a write, which can result
in a deadlock if 2 nodes are both blocking on a read a the same time, thus blocking their
respective writes (this is actually fairly easy to reproduce with a simple repair).
> So instead attaching a patch that uses one socket per thread.
> The patch also correct the stream throughput throttling calculation that was 8000 times
lower than what it should be.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message