Todd Lipcon has posted comments on this change. ( 
http://gerrit.cloudera.org:8080/9295 )

Change subject: [TestWorkload] an option to retry on read timeouts
......................................................................


Patch Set 3:

> In the context of TestWorkload, it's the same story as with write operations 
> -- if a timeout happens with a write operation, TestWorkload can ignore that 
> instead of crashing and retry.  That's how it's implemented now, right?  So, 
> the idea here is to do the same with timeouts for scan/read operations.

I think in many of the cases where we set write_timeout_allowed it's because 
we've explicitly set a very low timeout and expect timeouts. We want to stress 
cases where writes are hitting servers as they are going through various 
lifecycle transitions and the best way to do that is to always be starting new 
writes rather than waiting on previously completed ones.

Skimming the cases where we set_timeout_allowed right now for writes, it seems 
like most of them are the above case where we are also setting the timeout to 
150ms, 250ms, etc. There are a few where we are not doing that, and I wonder 
whether this is indicative of bugs in our client retry logic and we should be 
working to remove them.

So I guess that's all a long way to say: if we need to add this, let's also add 
(or find an existing) JIRA that we have cases where we aren't properly failing 
over scans in the case of timeouts.


--
To view, visit http://gerrit.cloudera.org:8080/9295
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I54a6b81e4ba3a55676f1fc97cd577a5fe545c550
Gerrit-Change-Number: 9295
Gerrit-PatchSet: 3
Gerrit-Owner: Alexey Serbin <aser...@cloudera.com>
Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <t...@apache.org>
Gerrit-Comment-Date: Tue, 13 Feb 2018 22:53:59 +0000
Gerrit-HasComments: No

Reply via email to