rschmitt commented on PR #709: URL: https://github.com/apache/httpcomponents-client/pull/709#issuecomment-3229793952
Oh, duh, I see your point now. You're saying that the HTTP/1.1 tests _think_ they're testing a race between connection leasing and half-close, but they're actually testing a race within the duplexer, between the write path (send the next pipelined request) and the read path (read and process connection closure). What I don't understand, then, is why the use of `StaleCheckCommand` [showed such an improvement](https://github.com/apache/httpcomponents-core/pull/547#issuecomment-3176830951) when combined with greedy reads in the HTTP/1.1 duplexer (i.e. read the input buffer until it returns 0 or -1). If `futures.add(sendPing(client))` causes the request to immediately be pipelined on an assigned connection, then `StaleCheckCommand` shouldn't make a difference, but in fact it makes a dramatic difference. When the connection pool is full, does the async client _ever_ just wait for a connection to become available, instead of pipelining the request onto an existing connection? Alternatively, is there logic within the client (independent of any `RetryStrategy`) that can take unsent pipelined requests and reassign them to another connection? I'll also check and see whether I can replicate my earlier experiment. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
