With http2, responses aren't returned until previous requests have returned #3278
Replies: 2 comments 5 replies
-
time.sleep(1)
delayed_fetch(6) # a: 1 - 7
time.sleep(1)
delayed_fetch(1) # b: 2 - 3
time.sleep(2)
delayed_fetch(6) # c: 4 - 10
time.sleep(1)
delayed_fetch(1) # d: 5 - 6
time.sleep(3)
delayed_fetch(1) # e: 8 - 9
It looks the thread for request
|
Beta Was this translation helpful? Give feedback.
-
I think it's a race in I managed to get a test run to complete according to the expected timeline only after I added additional logging. I then added even more logging and managed to get it to flip between the two behaviors intermittently: with Trace('_receive_events _read_lock outside', logger, request, {'stream_id': stream_id}):
with self._read_lock:
with Trace('_receive_events _read_lock inside', logger, request, {'stream_id': stream_id}):
if self._connection_terminated is not None:
|
Beta Was this translation helpful? Give feedback.
-
Hi! I think this is showing that, when http2 is enabled, when multiple threads send requests [to the same host?] through a single
Client
, the thread that first used theClient
is receiving all responses and holding them until its request's response is received. (When http2 is disabled, each request gets its own TCP session, and requests are processed immediately.)I have a mix of long polls and mutating RPCs to a single host, so what I'm seeing is that RPCs that are triggered by timers (instead of because a long poll just finished) are getting backed up until the current long poll ends. (And I presume multiple long polls will also back each other up.)
Beta Was this translation helpful? Give feedback.
All reactions