Connectivity checker causes further "port already in use" issue

[foosel]

Problem

As mentioned in #2038 (comment), there's still an issue with the connectivity checker causing "port already in use" issues on server startup.

The problem can only be observed on Windows (for Linux/Unix the intermediary server is now started in a way that it no longer inherits its socket to subprocesses - sadly that is not an option for Windows). It's caused by the connectivity check triggering an event during runtime of the intermediary server that in turn can trigger several subprocesses in the Software Update Plugin (for checking pip). If the timing is just right that causes the same "port already in use" issue on startup that was reported in #2035 and caused there by the file analysis.

Solution

Current idea to solve: Do not start connectivity check until after the actual tornado server runs. Additionally limit event propagation to plugins that have already been initialized (that was also a problem observed while debugging this further).

In the long run maybe look into reusing the same listening socket for both the intermediary server and tornado (might not be possible however and also feels like a hack).

[foosel]

Solved differently than originally anticipated:

• We no longer fire events before the "Startup" event has been seen. Anything sent before that gets buffered and sent after the startup event. That way nothing generating events during runtime of our intermediary server can have unforeseen side effects.
• We no longer forward events to uninitialized EventHandlerPlugin implementations.
• And most importantly, we can now tell the intermediary server socket to NOT inherit itself to any spawned subprocesses under Windows as well (which severely decreases the likelihood of this problem - usually either fcntl or the windows API should be available).

[foosel]

1.3.5 was released yesterday.