Steven Jacobs has posted comments on this change. Change subject: Redeploy channels and procedures during recovery ......................................................................
Patch Set 11: (2 comments) https://asterix-gerrit.ics.uci.edu/#/c/2641/11/asterix-bad/src/test/java/org/apache/asterix/bad/test/BADRecoveryTest.java File asterix-bad/src/test/java/org/apache/asterix/bad/test/BADRecoveryTest.java: Line 86: if (testNumber == 1) { > Sorry for the 2nd comment. What does this mean? The cluster gets stopped after the 0th test (line 95) and started again before the 1st test (line 88). Other than that we don't need to keep restarting the cluster. https://asterix-gerrit.ics.uci.edu/#/c/2641/11/asterix-bad/src/test/resources/recoveryts/queries/recovery/check_channels/check_channels.3.sleep.sqlpp File asterix-bad/src/test/resources/recoveryts/queries/recovery/check_channels/check_channels.3.sleep.sqlpp: Line 25: 25000 > why sleep 25 seconds? (This will make the bad test longer for every patch r I want to make absolutely certain that the channel is still executing. I know the tests can run on slower machines. There are several issues that lead me to make it this long: 1) I don't have confidence in making the channel period less than 5 seconds (even on my local build there are rare instances taking longer than 1 second to execute the tiny channel job. 2) The cluster deinit() has no precise timing, e.g. we don't know how long the channel was running before the cluster stopped. 3) The cluster init() also has no precise timing, so there's no way to guarantee how long the channel has been running before this sleep happens. Essentially I start the comparison much higher than expected (< 3 when we actually expect 0) to account for potential executions during the start and stop, so I have to add 15 seconds worth of time to make sure that we get to at least 3, and I also want to make sure that we increase, which is why I put 10 seconds more. I think by giving this much wiggle room we make sure to prevent random failures of the test. -- To view, visit https://asterix-gerrit.ics.uci.edu/2641 To unsubscribe, visit https://asterix-gerrit.ics.uci.edu/settings Gerrit-MessageType: comment Gerrit-Change-Id: I6897ccf9cddb9ec8d10256e252ee893afe6db145 Gerrit-PatchSet: 11 Gerrit-Project: asterixdb-bad Gerrit-Branch: master Gerrit-Owner: Steven Jacobs <sjaco...@ucr.edu> Gerrit-Reviewer: Jenkins <jenk...@fulliautomatix.ics.uci.edu> Gerrit-Reviewer: Steven Jacobs <sjaco...@ucr.edu> Gerrit-Reviewer: Xikui Wang <xkk...@gmail.com> Gerrit-HasComments: Yes