Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
pipelining: check for doomed connections #1075
Issue #627: Checks for doomed connections when selecting a connection for pipelining. Restores checks by Carlo Wood.
It appears that Rider-Linden hasn't had time to upstream this. We were bitten by this bug with our fork of their project and found this commit message as I can replicate the problem without issue on ethernet over powerline within my home. They have been using this fix / workaround for several months now.
So, I took the liberty of getting his fork rebased into a single commit and will fix any code quality changes that are recommended by the community.
Background: All connections start off in the 'close' state and later their protocol can turn that off, for example HTTP will default to persistent connections when its protocol specific function is called.
However, before the protocol specific function is called create_conn calls ConnectionExists and IsPipeliningPossible and so now that we are checking for the close bit in those functions the connections are not always pipelined, causing some tests to fail (530 584 1900 1902 1903).
I'm not sure about the best way to solve this, I don't know if this should be reverted for the moment or there is some easy fix I'm missing. It seems to me that we would need a separate bit to mark a connection as
changed the title from
Issue #627: Check for doomed connections
pipelining: check for doomed connections
Oct 16, 2016
These test failures are sort of proof why Pipelining is a pain to support in the first place (and I ultimately would like to remove that support in a future). The timing sensitivity is really hard to write reliable tests for. In this case, it really seems like the tests are to blame but I would feel very uncomfortable disabling these tests since Pipelining is already shaky as it is and reducing the number of pipelining tests further is like asking for more breakage to land.
This said, we can't have broken tests either so... I think we should revert the patch short-term and then see what we can do to fix the tests when trying to merge the fix back again.