Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Thu, 10 Mar 2016 00:13:40 +0000 (UTC)
From: "Yuki Morishita (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12945716.1456802522000.52816.1457568820865@Atlassian.JIRA>
In-Reply-To: <JIRA.12945716.1456802522000@Atlassian.JIRA>
References: <JIRA.12945716.1456802522000@Atlassian.JIRA>
 <JIRA.12945716.1456802522233@arcas>
Subject: [jira] [Commented] (CASSANDRA-11286) streaming socket never times
 out
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CASSANDRA-11286?page=3Dcom.atla=
ssian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=
=3D15188344#comment-15188344 ]=20

Yuki Morishita commented on CASSANDRA-11286:
--------------------------------------------

+1. Will commit.

> streaming socket never times out
> --------------------------------
>
>                 Key: CASSANDRA-11286
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1128=
6
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Streaming and Messaging
>            Reporter: Paulo Motta
>            Assignee: Paulo Motta
>
> While trying to reproduce CASSANDRA-8343 I was not able to trigger a {{So=
cketTimeoutException}} by adding an artificial sleep longer than {{streamin=
g_socket_timeout_in_ms}}.
> After investigation, I detected two problems:
> * {{ReadableByteChannel}} creation via {{socket.getChannel()}}, as done i=
n {{ConnectionHandler.getReadChannel(socket)}}, does not respect {{socket.s=
etSoTimeout()}}, as explained in this [blog post|https://technfun.wordpress=
.com/2009/01/29/networking-in-java-non-blocking-nio-blocking-nio-and-io/]
> ** bq. The only difference between =E2=80=9Cblocking NIO=E2=80=9D and =E2=
=80=9CNIO wrapped around IO=E2=80=9D is that you can=E2=80=99t use socket t=
imeout with SocketChannels. Why ? Read a javadoc for setSocketTimeout(). It=
 says that this timeout is used only by streams.
> * {{socketSoTimeout}} is never set on "follower" side, only on initiator =
side via {{DefaultConnectionFactory.createConnection(peer)}}.
> This may cause streaming to hang indefinitely, as exemplified by CASSANDR=
A-8621:
> bq. For the scenario that prompted this ticket, it appeared that the stre=
aming process was completely stalled. One side of the stream (the sender si=
de) had an exception that appeared to be a connection reset. The receiving =
side appeared to think that the connection was still active, at least in te=
rms of the netstats reported by nodetool. We were unable to verify whether =
this was specifically the case in terms of connected sockets due to the fac=
t that there were multiple streams for those peers, and there is no simple =
way to correlate a specific stream to a tcp session.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)