test_introducer.SystemTest: fix race condition
authorBrian Warner <warner@lothar.com>
Sat, 31 Mar 2012 00:29:06 +0000 (17:29 -0700)
committerBrian Warner <warner@lothar.com>
Sat, 31 Mar 2012 00:29:06 +0000 (17:29 -0700)
commit24812905a1da3ada28c0177f755bff62f3228123
tree87f82d0a7bf5adc93cb505b3a31119f23bb072ce
parentc5e10e2261f4737582a18b718ff88e0a2807046a
test_introducer.SystemTest: fix race condition

SystemTest has a couple of different phases, separated by a poller which
waits for everything to be idle (all messages delivered, none in flight). It
does this by watching some internal "_debug_outstanding" counters in the
server and in each client, and waiting for them to hit zero.

Just before the last phase, we replace the server with a new one (to make
sure clients re-send their messages properly). Unfortunately, the polling
function closed over the variable holding the original server, and didn't see
the replacement. It kept polling the old server, and failed to notice the
outstanding messages for the new server. The last phase of the test (check3)
was started too early, which failed (since some messages had not yet been
delivered), and then exploded in a flurry of dirty-reactor errors (because
some messages were delivered after test shutdown).

This replaces the closed-over-variable with a "self.the_introducer", which
seems to fix the race.

One additional place to look at in the future: the client
announcement-receive path (remote_announce) uses an eventually(). If the
message has been received and the eventual-send posted (but not yet executed)
when the poller sees it, the poller might erroneously conclude that the
client is idle and cause the same problem as above. To fix this, the poller
(probably all pollers) could be enhanced to do a flushEventualQueue before
querying the are-we-done-yet predicate function.
src/allmydata/test/test_introducer.py