Adar Dembo has posted comments on this change.

Change subject: [java client] ITClient's new snapshot scanners can easily 
timeout
......................................................................


Patch Set 1:

(1 comment)

http://gerrit.cloudera.org:8080/#/c/4545/1/java/kudu-client/src/test/java/org/apache/kudu/client/ITClient.java
File java/kudu-client/src/test/java/org/apache/kudu/client/ITClient.java:

PS1, Line 416:       // It's possible to get timeouts if we're unlucky. A 
particularly common one is
             :       // "could not wait for desired snapshot timestamp to be 
consistent" since we're using
             :       // READ_AT_SNAPSHOT scanners.
             :       if (e.getStatus().isTimedOut()) {
             :         LOG.warn("Received a scan timeout", e);
             :         return true;
             :       }
> This made me think that timing out is the expected behavior:
I see. That comment assumes that the client will retry, though. Why isn't it 
retrying? When the client sees the server-side timeout, shouldn't it compare 
the overall scan deadline with the current time and decide to retry?

If that worked correctly, you could bump the scan timeout and everything would 
behave as expected: the server would time out a scan request early (thus 
freeing up an RPC handler thread) and the client would retry, until the scan 
succeeds or the real timeout is actually reached.


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

Gerrit-MessageType: comment
Gerrit-Change-Id: I08de2fcd6736c2bc75ef0c92c8c8f48f9d7da49e
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Jean-Daniel Cryans <jdcry...@apache.org>
Gerrit-Reviewer: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>
Gerrit-Reviewer: David Ribeiro Alves <dral...@apache.org>
Gerrit-Reviewer: Jean-Daniel Cryans <jdcry...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-HasComments: Yes

Reply via email to