Do not disconnect on SSL_ERROR_WANT_WRITE

[skizunov]

In certain cases, when using Python 3.5+, SSLSocket.send may
raise ssl.SSL_ERROR_WANT_WRITE when the socket is not currently
able to write. The previous behavior would close the connection.
The new behavior is to treat this just like an EWOULDBLOCK
socket error which is what this is analogous to.

Signed-off-by: Sergey Kizunov sergey.kizunov@ni.com

[codecov]

Codecov Report

Merging #928 into master will decrease coverage by 0.41%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master     #928      +/-   ##
==========================================
- Coverage   82.42%   82.01%   -0.42%     
==========================================
  Files          20       21       +1     
  Lines        3636     3781     +145     
  Branches      540      562      +22     
==========================================
+ Hits         2997     3101     +104     
- Misses        494      521      +27     
- Partials      145      159      +14

Impacted Files	Coverage Δ
pika/adapters/base_connection.py	63.81% <0%> (-1.79%)	⬇️
pika/adapters/asyncio_connection.py	58.44% <0%> (-1.3%)	⬇️
pika/__init__.py	100% <0%> (ø)	⬆️
pika/adapters/libev_connection.py	73.43% <0%> (ø)
pika/adapters/blocking_connection.py	84.87% <0%> (+0.13%)	⬆️
pika/adapters/__init__.py	77.27% <0%> (+5.05%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 35169f8...32723b8. Read the comment docs.

[lukebakken]

Thanks. Is there any way to reproduce this?

[skizunov]

@lukebakken : I saw this on Windows 7 on a lower spec'ed machine. Using Python 3.6.4, and aBlockingConnection on an SSL connection, just keep writing data using Channel.publish in a tight loop. With the previous code, it would disconnect. You won't see the issue if you put a small time.sleep between calls to Channel.publish.

[anton-ryzhov]

I've faced with this bug too. Hope this fix will be in release soon.

Reproduction is very simple — use 3.5+ and send one big message (100k in my case for real network, may be bigger for localhost). If this message will be bigger than underlying socket buffer — you'll get the error.

Also doc says that both recv and send may cause both SSLWantReadError or SSLWantWriteError, but pika now handles only one.

[vitaly-krugl]

Also doc says that both recv and send may cause both SSLWantReadError or SSLWantWriteError, but pika now handles only one.

That possibility of either SSLWantReadError or SSLWantWriteError in recv and send may be triggered by TLS renegotiation. Being addressed in the refactoring pull request #1002. I could definitely use some help writing test code to validate that it works in the renegotiation scenario.