[
https://issues.apache.org/jira/browse/CASSANDRA-9061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tyler Hobbs updated CASSANDRA-9061:
-----------------------------------
Attachment: 9061-suggested.txt
I think we can take a somewhat simpler approach. I've attached a patch that is
untested but demonstrates roughly what I'm thinking of. (Most of the diff is
just an indentation change.)
I don't think we really need to track in-progress or successful operations. We
can rely on the connection's {{in_flight}} count to know if there are
in-progress operations. Successful operations don't require any further
action. We don't need to track the request ID, because it's automatically
released by the connection when it gets a response, and we can easily get a new
one. Am I missing something in my suggested approach?
I think we're going to need a dtest to exercise this. You could start from
{{cqlsh_tests.TestCqlsh.test_copy_to()}}, setting a low enough write timeout
that a large number of operations fail.
> Add backoff and recovery to cqlsh COPY FROM when write timeouts occur
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-9061
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9061
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Reporter: Tyler Hobbs
> Assignee: Carl Yeksigian
> Priority: Minor
> Labels: cqlsh
> Fix For: 2.1.x
>
> Attachments: 9061-2.1.txt, 9061-suggested.txt
>
>
> Previous versions of COPY FROM didn't handle write timeouts because it was
> rarely fast enough for that to matter. Now that performance has improved,
> write timeouts are more likely to occur. We should handle these by backing
> off and retrying the operation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
