Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 1 Mar 2016 03:22:18 +0000 (UTC)
From: "Paulo Motta (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12945716.1456802522000.179700.1456802538245@Atlassian.JIRA>
In-Reply-To: <JIRA.12945716.1456802522000@Atlassian.JIRA>
References: <JIRA.12945716.1456802522000@Atlassian.JIRA>
 <JIRA.12945716.1456802522233@arcas>
Subject: [jira] [Created] (CASSANDRA-11286) streaming socket never times out
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Paulo Motta created CASSANDRA-11286:
---------------------------------------

             Summary: streaming socket never times out
                 Key: CASSANDRA-11286
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11286
             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 {{Sock=
etTimeoutException}} by adding an artificial sleep longer than {{streaming_=
socket_timeout_in_ms}}.

After investigation, I detected two problems:
* {{ReadableByteChannel}} creation via {{socket.getChannel()}}, as done in =
{{ConnectionHandler.getReadChannel(socket)}}, does not respect {{socket.set=
SoTimeout()}}, as explained in this [blog post|https://technfun.wordpress.c=
om/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 si=
de via {{DefaultConnectionFactory.createConnection(peer)}}.

This may cause streaming to hang indefinitely, as exemplified by CASSANDRA-=
8621:
bq. For the scenario that prompted this ticket, it appeared that the stream=
ing process was completely stalled. One side of the stream (the sender side=
) had an exception that appeared to be a connection reset. The receiving si=
de appeared to think that the connection was still active, at least in term=
s of the netstats reported by nodetool. We were unable to verify whether th=
is was specifically the case in terms of connected sockets due to the fact =
that there were multiple streams for those peers, and there is no simple wa=
y to correlate a specific stream to a tcp session.


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