Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
[tests] fix disconnect_ban intermittency #10376
Conversation
|
Sorry, but I was not able to reproduce the failure on my systems, so I can't provide tested ACK. Out of 1000 runs, I have got 8 of this only:
Ie. the already known and reported issue #9317 (comment), nothing else. |
fanquake
added
the
Tests
label
May 10, 2017
|
@paveljanik - can you try running the test when you have a lot of disk access happening in parallel which could block disk i/o for the node under test. One way to do this is to run in parallel with pruning.py which does a lot of stop/starts (and therefore flushes to disk a lot). You can do that by changing the BASE_SCRIPTS list in test_runner to something like: BASE_SCRIPTS= [
'pruning.py',
'disconnect_ban.py --portseed=1',
'disconnect_ban.py --portseed=2',
'disconnect_ban.py --portseed=3',
'disconnect_ban.py --portseed=4',
... |
|
utACK 3ba2c08 |
|
Concept ACK |
|
I was not able to reproduce, sorry. But reading the code, utACK 3ba2c08 |
jnewbery commentedMay 9, 2017
Fixes another functional test race. disconnect_ban.py bans a subnet with a one second expiry and then immediately tests that the subnet is banned. Due to the #10234, calls to
listbanned()now result in a disk flush, which can block on busy systems (for example when running multiple functional tests in parallel).Fix is to use mocktime to control when the ban expires.