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 <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Dan Burkert <[email protected]> Gerrit-Reviewer: David Ribeiro Alves <[email protected]> Gerrit-Reviewer: Jean-Daniel Cryans <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-HasComments: Yes
