[
https://issues.apache.org/jira/browse/CASSANDRA-17510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Meredith updated CASSANDRA-17510:
-------------------------------------
Status: Ready to Commit (was: Review In Progress)
Starting commit
CI Results (pending):
||Branch||Source||Circle CI||Jenkins||
|trunk|[branch|https://github.com/jonmeredith/cassandra/tree/commit_remote_branch/CASSANDRA-17510-trunk-B3E1BE3E-2AA9-476D-BD84-B1705032EA2F]|[build|https://app.circleci.com/pipelines/github/jonmeredith/cassandra?branch=commit_remote_branch%2FCASSANDRA-17510-trunk-B3E1BE3E-2AA9-476D-BD84-B1705032EA2F]|[build|https://ci-cassandra.apache.org/job/Cassandra-devbranch/1554/]|
> Streaming sessions longer than 3 minutes fail with timeout
> ----------------------------------------------------------
>
> Key: CASSANDRA-17510
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17510
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Streaming
> Reporter: Jon Meredith
> Assignee: Jon Meredith
> Priority: Normal
> Fix For: 4.1
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Streaming sessions that take longer than 3 minutes will fail with an
> InputTimeoutException on the streaming control channel connection.
> CASSANDRA-16927 refactored the streaming code as part of CEP-10 to clean up
> some abstractions. As part of those changes the StreamDeserializingTask
> (formerly StreamingInboundHandler) had a check removed that ensured data was
> present before reading from the AsyncStreamingInputPlus used by
> NettyStreamingChannel to pass incoming bytes to be deserialized off the main
> Netty event loop threads. When {{reBuffer}ing from the input,
> AsyncStreamingInputPlus times out if no data is received in three minutes.
> It is perfectly valid for no messages to be received over the control
> connection for longer than three minutes - pre CASSANDRA-16927 just doesn’t
> do the read until data is present, so it doesn’t hit the timeout. A possible
> solution is to replace throwing the InputTimeoutException with a check that
> the channel is still open and retry.
> Note this is unrelated to the streaming protocol KeepAlive removal - that had
> a default timeout of five minutes so would not have been effective anyway.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
