race in TestDeepStressStaysSane
Bug #1695128 reported by
Ian Booth
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Canonical Juju |
Fix Released
|
High
|
John A Meinel | ||
2.2 |
Fix Released
|
Medium
|
John A Meinel |
Bug Description
Changed in juju: | |
milestone: | 2.2-rc1 → none |
Changed in juju: | |
status: | In Progress → Fix Committed |
status: | Fix Committed → In Progress |
Changed in juju: | |
milestone: | 2.3-beta1 → 2.3-beta2 |
Changed in juju: | |
milestone: | 2.3-beta2 → 2.3-beta1 |
Changed in juju: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
Wow. The test is supposed to run in about 3s, using 3 slots for pinger. In this case it actually runs in 50s, and I have the feeling its the sort of "hung not doing anything for 48s, and then goes into a mad dash and finishes everything in 2s which means our counts are off.)
The test thought it was being generous by saying "pingers shouldn't trigger more than 4 active pingers in a given window", but when your load is off by a factor of 10x, the measurements can be a bit off.
And we don't want to give ourselves too large of a window, because then we wouldn't actually be testing that pruning is doing anything.
In this particular case, we were only off by about 5 pings out of 2000, but given we should really be more like 500 pings total our 'generous window of 1500 extra' wasn't enough.
I'll think about whether I can redesign it to pay explicit attention to how many pingers fired in the last window that shouldn't be pruned.