Issues in long running script

[ojii]

We're using hyper in a long running script, opening a single connection and re-using it. So far we've encountered two problems with that, though it looks like both are a manifestation of the same thing, the connection being closed by the remote end. I don't think this is something hyper can/should handle itself, but maybe it should raise more obvious errors (that are also easier to catch).

The first issue we had was HTTP20Connection._sock becoming None, making HTTP20Connection.get_response fail with AttributeError: 'NoneType' object has no attribute 'recv'. Our solution for now is to simply wrap our request/response code in try/except and re-establishing the connection on error.

The second one we get is SSLError: ('The read operation timed out',) again in HTTP20Connection.get_response. This could just be a networking issue and not a connection being closed, but we're not sure.

If anyone knows some tricks using hyper in very long running scripts, I'd love to hear them.

[Lukasa]

Hi @ojii!

It's entirely possible that there are real problems here: because HTTP/2 uses long-running connections, handling the logic in a clean way is a bit tricky and we haven't gotten around to solving that problem yet.

In the first instance, are you running hyper from PyPI or from the GitHub development branch? Several patches have gone into the development branch that may help resolve this issue, so if it's possible it'd be really interesting if you ran the development branch for a bit to see if you have some problems.

Re-establishing connections on an error is a really good idea, and it's something I'm interested in doing right, but signalling it is really tricky. I'm open to ideas here.

[ojii]

In the first instance, are you running hyper from PyPI or from the GitHub development branch? Several patches have gone into the development branch that may help resolve this issue, so if it's possible it'd be really interesting if you ran the development branch for a bit to see if you have some problems.

We're running hyper==0.5.0 (from PyPI). I will see if there's a good way for us to test with hyper straight from Github. Are there any plans for new PyPI releases in the near future?

Re-establishing connections on an error is a really good idea, and it's something I'm interested in doing right, but signalling it is really tricky. I'm open to ideas here.

I'm not sure hyper should magically reconnect, but a meaningful error that users could catch would be really nice.

[Lukasa]

Are there any plans for new PyPI releases in the near future?

There are, though right now I'm totally slammed working on a number of Python HTTP/2 things which means I'm stretched pretty thin. I have a few more improvements I'd like to make before releasing the next PyPI release, ideally, though at this point we may have diverged far enough from the current PyPI release that I should just bite the bullet and ship what we have.

[tbetbetbe]

👍 for a release cut.

Including the concurrency branch via #232 would lead to much 😂 but I understand if you want to hold off on that for a bit.

[tbetbetbe]

The second one we get is SSLError: ('The read operation timed out',) again in HTTP20Connection.get_response. This could just be a networking issue and not a connection being closed, but we're not sure.

FYI, this particular issue might be addressed by #221

[ojii]

FYI, this particular issue might be addressed by #221

that patch looks very promising. thank you.

[Lukasa]

@tbetbetbe Amusingly, the switch to use hyper-h2 basically makes the concurrency branch wrong at the moment (as I discovered when I tried to integrate it), because the I/O and state changes have moved all over the place. However, I'll take a look at trying to rebuild the concurrency stuff from scratch. =)

Right now the biggest thing blocking the release is that hyper-h2 doesn't have an API for plaintext upgrade, which was previously supported and so I should re-establish.

[Lukasa]

Uhh....I really should read my emails in chronological order, because if I had I'd have known that you did that already @tbetbetbe! I'll dive into your patch. ;)