Yuqi Du has posted comments on this change. ( http://gerrit.cloudera.org:8080/18420 )
Change subject: [java] Fix a scan bug which will read repetitive rows. ...................................................................... Patch Set 16: (17 comments) http://gerrit.cloudera.org:8080/#/c/18420/15//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/18420/15//COMMIT_MSG@12 PS15, Line 12: In common scenarios, when tablet serv > nit: how about Done http://gerrit.cloudera.org:8080/#/c/18420/15//COMMIT_MSG@12 PS15, Line 12: e > nit: often Done http://gerrit.cloudera.org:8080/#/c/18420/15//COMMIT_MSG@13 PS15, Line 13: restarts, Scanners will rea > nit: how about Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/main/java/org/apache/kudu/client/AsyncKuduScanner.java File java/kudu-client/src/main/java/org/apache/kudu/client/AsyncKuduScanner.java: http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/main/java/org/apache/kudu/client/AsyncKuduScanner.java@693 PS15, Line 693: if (isFaultTolerant && resp.lastPrimaryKey != null) { > Nice catch! BTW, in looking at the differences between 'cb' defined at L558 ok. I think you are right. Now resource metrics no problem, and exteral consisency propagated timestamp is a little complex, and I'll take some time to confirm it. As you said, the two infos update can fix at another commit. http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITFaultTolerantScanner.java File java/kudu-client/src/test/java/org/apache/kudu/client/ITFaultTolerantScanner.java: http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITFaultTolerantScanner.java@46 PS15, Line 46: tserver in the > nit: use either 'tablet server' or 'tserver', but not 'tserver server' Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITFaultTolerantScanner.java@48 PS15, Line 48: the > nit: the Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITFaultTolerantScanner.java@48 PS15, Line 48: injection ha > nit: ... injection happens at ... Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java File java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java: http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@54 PS15, Line 54: 90000 > Just curious: is it crucial to have 90000 instead of 20000 for some reason? The table has 3 tablets. In the testcase, we pick a tablet, need to send 2 scan requests to the leader replica at least. A ScanRequest' response maybe has many rows, the response's row count is not controlled by request, basicly decided by 1MB and average row size. So I think using a larger ROW_COUNT is ok and cover the case, although it's not good enough. All testcases has passed, maybe some tests slower than before, but I didnot feel it. http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@83 PS15, Line 83: harness.getClient().isCreateTableDone(TABLE_NAME)) > nit: why to add this? Maybe, just add one more retry instead just for the I just don't waste the last 1 second. http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@109 PS15, Line 109: Log on error details. > nit: how about Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@192 PS15, Line 192: Inject fa > nit: Inject Sentences below removed. http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@195 PS15, Line 195: e sc > nit: scanning Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@195 PS15, Line 195: g and a non-fault tolerant > nit: a non-fault tolerant scanner Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@195 PS15, Line 195: a fault tolerant scann > nit: a fault tolerant scanner Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@217 PS15, Line 217: ltInjection = ena > nit: enableFaultInjection Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@237 PS15, Line 237: (rri.hasNext()) > nit: faultInjected ? Done http://gerrit.cloudera.org:8080/#/c/18420/15/java/kudu-client/src/test/java/org/apache/kudu/client/ITScannerMultiTablet.java@289 PS15, Line 289: * Injecting failures (i.e. drop clien > What's the significance of this assertion? Could it ever happen that after Removed. -- To view, visit http://gerrit.cloudera.org:8080/18420 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I4d6be9df10c1a45cd971b52a0351028c1f5a023f Gerrit-Change-Number: 18420 Gerrit-PatchSet: 16 Gerrit-Owner: Yuqi Du <[email protected]> Gerrit-Reviewer: Alexey Serbin <[email protected]> Gerrit-Reviewer: Andrew Wong <[email protected]> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Yifan Zhang <[email protected]> Gerrit-Reviewer: Yingchun Lai <[email protected]> Gerrit-Reviewer: Yuqi Du <[email protected]> Gerrit-Comment-Date: Tue, 26 Apr 2022 08:33:51 +0000 Gerrit-HasComments: Yes
