498912 - Thunderbird mozmill test driver occasionally dies with ECONNREFUSED

Status: RESOLVED WORKSFORME

(Thunderbird :: General, defect)

Description

[Andrew Sutherland [:asuth] (he/him)]

+++ This bug was initially created as a clone of Bug #498535 +++

Migrating my commentary from bug 498535 to its own bug since it is its own problem.

Sometimes the test runner dies with an ECONNREFUSED exception, I believe the story goes something like this:

1) Thunderbird starts up, jsbridge accepts connections.
2) jsbridge's wait_and_create_network method successfully connects to that Thunderbird instance.  (It has an initial loop that expects socket failures up until the time when it connects successfully.)
3) Thunderbird restart logic shuts down thunderbird and the jsbridge listener.
4) The jsbridge logic tries to connect (thinking Thunderbird is now up for good), but since Thunderbird and jsbridge are dead, it gets ECONNREFUSED and dies.
5) Thunderbird comes back, but it doesn't matter because runtest.py is dead.

Ideally, we could avoid running Thunderbird in a situation where it needs to restart, so the situation is avoided entirely.  Unfortunately, I'm pretty sure things don't work at all if we preclude reloads.  We should probably be able to get away with forcing an explicit earlier step that causes the required XPCOM registrations to happen, although I vaguely recall trying that and having difficulties.

Comment 1

[Mark Banner (:standard8)]

Are we setting/handling with environment variable NO_EM_RESTART=1 ? I thought mozmill did that but maybe not. Really that should be able to avoid restarts.

Comment 2

[David :Bienvenu]

Mozmill requires that *not* to be set, because it does a restart to hook up the jsbridge stuff, afaict.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

Yeah, I had NO_EM_RESTART when I originally was playing with things, but as bienvenu says, jsbridge had issues.  So I let it restart and things started working.  There are probably ways to mitigate... the fact that the ECONNREFUSED happens at all suggests that jsbridge does in fact (at least in some cases) start up in the process that gets restarted.

Comment 4

[Mikeal Rogers [:mikeal] (mrogers@)]

This is fixed in the latest github. We just increased the timeout when waiting for the product to come up and bind to the port.

The default timeout is also now a module level variable so if it's still too short for thunderbird you can customize it in runtest.py.

A new release of jsbridge should get pushed later today.

Comment 5

[Magnus Melin [:mkmelin]]

mozmill is gone.