You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@kudu.apache.org by "Tony Foerster (Code Review)" <ge...@cloudera.org> on 2018/07/10 17:02:04 UTC
[kudu-CR] Fix flaky 'Random Backup and Restore' test
Tony Foerster has uploaded this change for review. ( http://gerrit.cloudera.org:8080/10902
Change subject: Fix flaky 'Random Backup and Restore' test
......................................................................
Fix flaky 'Random Backup and Restore' test
Add time to the snapshot timestamp to make sure all records written to
test table are read by the backup job. Job would fail ~1/3 of the time
before.
I also tried using a timestamp obtained from the KuduClient:
```
val snapshotTimestampMicros = HybridTimeUtil.HTTimestampToPhysicalAndLogical(kuduClient.getLastPropagatedTimestamp)(0)
val snapshotTimestampMillis = snapshotTimestampMicros / 1000
```
The above code would produce something withing 1ms of the System
timestamp. Not sure of the root cause, I'd expect the timetamp obtained
from the Kudu client to work.
Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
---
A java/kudu-backup/out/test/resources/log4j.properties
M java/kudu-backup/src/test/scala/org/apache/kudu/backup/TestKuduBackup.scala
2 files changed, 28 insertions(+), 1 deletion(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/02/10902/1
--
To view, visit http://gerrit.cloudera.org:8080/10902
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
Gerrit-Change-Number: 10902
Gerrit-PatchSet: 1
Gerrit-Owner: Tony Foerster <to...@phdata.io>
[kudu-CR] Fix flaky 'Random Backup and Restore' test
Posted by "Tony Foerster (Code Review)" <ge...@cloudera.org>.
Tony Foerster has abandoned this change. ( http://gerrit.cloudera.org:8080/10902 )
Change subject: Fix flaky 'Random Backup and Restore' test
......................................................................
Abandoned
This is a bad workaround and the core issue should be fixed.
--
To view, visit http://gerrit.cloudera.org:8080/10902
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: abandon
Gerrit-Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
Gerrit-Change-Number: 10902
Gerrit-PatchSet: 2
Gerrit-Owner: Tony Foerster <an...@gmail.com>
Gerrit-Reviewer: Adar Dembo <ad...@cloudera.com>
Gerrit-Reviewer: Grant Henke <gr...@apache.org>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Tony Foerster <an...@gmail.com>
[kudu-CR] Fix flaky 'Random Backup and Restore' test
Posted by "Tony Foerster (Code Review)" <ge...@cloudera.org>.
Hello Kudu Jenkins, Adar Dembo,
I'd like you to reexamine a change. Please visit
http://gerrit.cloudera.org:8080/10902
to look at the new patch set (#2).
Change subject: Fix flaky 'Random Backup and Restore' test
......................................................................
Fix flaky 'Random Backup and Restore' test
Add time to the snapshot timestamp to make sure all records written to
test table are read by the backup job. Job would fail ~1/3 of the time
before.
I also tried using a timestamp obtained from the KuduClient:
```
val snapshotTimestampMicros = HybridTimeUtil.HTTimestampToPhysicalAndLogical(kuduClient.getLastPropagatedTimestamp)(0)
val snapshotTimestampMillis = snapshotTimestampMicros / 1000
```
The above code would produce something within 1ms of the System
timestamp. Not sure of the root cause, I'd expect the timetamp obtained
from the Kudu client to work.
Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
---
M java/kudu-backup/src/test/scala/org/apache/kudu/backup/TestKuduBackup.scala
1 file changed, 5 insertions(+), 1 deletion(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/02/10902/2
--
To view, visit http://gerrit.cloudera.org:8080/10902
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
Gerrit-Change-Number: 10902
Gerrit-PatchSet: 2
Gerrit-Owner: Tony Foerster <to...@phdata.io>
Gerrit-Reviewer: Adar Dembo <ad...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
[kudu-CR] Fix flaky 'Random Backup and Restore' test
Posted by "Adar Dembo (Code Review)" <ge...@cloudera.org>.
Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/10902 )
Change subject: Fix flaky 'Random Backup and Restore' test
......................................................................
Patch Set 1:
(3 comments)
http://gerrit.cloudera.org:8080/#/c/10902/1//COMMIT_MSG
Commit Message:
http://gerrit.cloudera.org:8080/#/c/10902/1//COMMIT_MSG@20
PS1, Line 20: The above code would produce something withing 1ms of the System
within
http://gerrit.cloudera.org:8080/#/c/10902/1//COMMIT_MSG@21
PS1, Line 21: Not sure of the root cause, I'd expect the timetamp obtained
: from the Kudu client to work.
I would too, but only if there were rows actually written; otherwise there'd be no propagated timestamp. Can you double check that the failures weren't all correlated with test runs where the number of rows written were 0?
Grant, if you're reading, could you look into this?
http://gerrit.cloudera.org:8080/#/c/10902/1/java/kudu-backup/out/test/resources/log4j.properties
File java/kudu-backup/out/test/resources/log4j.properties:
PS1:
What does this file do? I'm asking because it's in a non-standard Maven location (kudu-backup/out/test/resources vs. something like kudu-backup/src/test/sources).
--
To view, visit http://gerrit.cloudera.org:8080/10902
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
Gerrit-Change-Number: 10902
Gerrit-PatchSet: 1
Gerrit-Owner: Tony Foerster <to...@phdata.io>
Gerrit-Reviewer: Adar Dembo <ad...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Comment-Date: Tue, 10 Jul 2018 21:09:23 +0000
Gerrit-HasComments: Yes
[kudu-CR] Fix flaky 'Random Backup and Restore' test
Posted by "Tony Foerster (Code Review)" <ge...@cloudera.org>.
Tony Foerster has posted comments on this change. ( http://gerrit.cloudera.org:8080/10902 )
Change subject: Fix flaky 'Random Backup and Restore' test
......................................................................
Patch Set 1:
(2 comments)
http://gerrit.cloudera.org:8080/#/c/10902/1//COMMIT_MSG
Commit Message:
http://gerrit.cloudera.org:8080/#/c/10902/1//COMMIT_MSG@21
PS1, Line 21: Not sure of the root cause, I'd expect the timetamp obtained
: from the Kudu client to work.
> I would too, but only if there were rows actually written; otherwise there'
The row counts are always off by one:
org.apache.kudu.backup.TestKuduBackup > Random Backup and Restore FAILED
java.lang.AssertionError: expected:<191> but was:<190>
http://gerrit.cloudera.org:8080/#/c/10902/1/java/kudu-backup/out/test/resources/log4j.properties
File java/kudu-backup/out/test/resources/log4j.properties:
PS1:
> What does this file do? I'm asking because it's in a non-standard Maven loc
My mistake, this should not have been committed. I'm not sure why the non-standard 'out' location, I thought it just hadn't been added to the .gitignore. Not sure what command I ran to create it.
--
To view, visit http://gerrit.cloudera.org:8080/10902
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I51a6dbeeb064dff157609fdbbafe505668eb2b26
Gerrit-Change-Number: 10902
Gerrit-PatchSet: 1
Gerrit-Owner: Tony Foerster <to...@phdata.io>
Gerrit-Reviewer: Adar Dembo <ad...@cloudera.com>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Tony Foerster <to...@phdata.io>
Gerrit-Comment-Date: Thu, 12 Jul 2018 13:29:10 +0000
Gerrit-HasComments: Yes