Replies: 3 comments 3 replies
-
|
So, you shouldn't need to do anything here...
Having said that, we have seen issues specifically with Question really is what problem exactly are you seeing, and what's the traceback? Either ways around, you don't need to close/reopen the client instance. That just drops the entire connection pool and isn't what you need. Worst case scenario is that you need to retry a request. Note that the sync client, and the trio async backend are both way more reliable wrt regard detecting dropped connections. Although there's always some possibility of a connection being dropped/timing out unexpectedly just as a new request is starting to be sent over it. |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
Thanks for the quick response! Happy to add some more context here. I am indeed using asyncio. The machine I was just testing this on has Python 3.7 set up in Catalina. I also just made sure that httpx is at the latest version (0.17.1). I removed the "_reset_client" call and that seems to be working, so indeed all that is needed is a singly retry - thanks for that. Nevertheless it seems like this might be an asyncio-related bug if the expected behavior is a transparent replacement of the connection before the request is attempted to be sent. I'll also investigate whether we can safely switch to trio as our underlying async backend. P.S. if this is a bug, should I close this discussion and open this as an issue instead? |
Beta Was this translation helpful? Give feedback.
-
|
I think I'm having the same issue. I came up with this demo that reproduces the issue unreliably. Running it five times should provide at least one "Connection reset by peer" traceback. I've reproduced this issue with httpx 0.17.1 and 0.18.0. import asyncio
import httpx
client = httpx.AsyncClient()
async def main():
await client.get('https://imdb.com/')
await asyncio.sleep(120)
await client.get('https://imdb.com/')
asyncio.get_event_loop().run_until_complete(main())
asyncio.get_event_loop().run_until_complete(client.aclose())Traceback |
Beta Was this translation helpful? Give feedback.
-
|
Okay, the latest release of
|
Beta Was this translation helpful? Give feedback.
1 reply
-
|
That seems to fix it indeed. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
A reliable reproduction, from #1459 (comment) is this... server.py import _socket
import asyncio
import io
import struct
import httpx
async def server_with_force_reset():
async def respond_then_die(reader, writer):
# Read request -- as we should
await reader.readuntil(b"\r\n\r\n")
# Send HTTP headers and data, indicating "keep-alive"
writer.write(
b"HTTP/1.1 200 OK\r\nContent-Length:3\r\nContent-Type:text/plain\r\n\r\nend"
)
await writer.drain()
# Force a TCP RST packet
# http://deepix.github.io/2016/10/21/tcprst.html
fd = writer._transport._sock.fileno()
linger = struct.pack("=II", 1, 0)
_socket.socket(fileno=fd).setsockopt(
_socket.SOL_SOCKET, _socket.SO_LINGER, bytearray(linger)
)
writer.close()
server = await asyncio.start_server(respond_then_die, "127.0.0.1", 8888)
async with server:
await server.serve_forever()
asyncio.run(server_with_force_reset())client.py import asyncio
import httpx
async def main():
async with httpx.AsyncClient() as client:
r = await client.get('http://127.0.0.1:8888/')
print(r)
r = await client.get('http://127.0.0.1:8888/')
print(r)
asyncio.run(main()) |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a long-lived AsyncClient in my app that is used to make many calls to the same (or same set) of servers over and over again for an indefinite time. Of course, re-using connections is very advantageous in that scenario, however there are also "downtimes" during which no or only few requests will be made. This leads to the connection being closed by the remote, at which point the next request the client makes will fail.
The following is a simplified version of how I'm currently working around this, but it seems a bit ugly and I'm somewhat worried about a) catching the wrong exception and b) repeating the request (unsolicited repeat requests are a problem in my use-case).
For my specific questions:
Beta Was this translation helpful? Give feedback.
All reactions