Jean-Daniel Cryans 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; : } > I see. That comment assumes that the client will retry, though. Why isn't i I think the problem here is that we cannot distinguish between a timeout caused by "could not wait for desired snapshot timestamp" and an RPC-level timeout. We could introspect the message but it seems flaky. IMO this is one of those "gray zones" in our APIs. -- 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