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

Reply via email to