rschmitt commented on PR #547: URL: https://github.com/apache/httpcomponents-core/pull/547#issuecomment-3198323155
It looks like I was right about HTTP/2. The race condition statistics are exactly the same as for HTTP/1.1: ``` h2: Validation disabled: Sequential requests (slow): 10 succeeded; 0 failed (100.00% success rate) h2: Validation enabled: Sequential requests (slow): 10 succeeded; 0 failed (100.00% success rate) h2: Validation disabled: Sequential requests (rapid): 2,473 succeeded; 27 failed (98.92% success rate, 0.00% retriable) h2: Validation enabled: Sequential requests (rapid): 2,500 succeeded; 0 failed (100.00% success rate) h2: Validation disabled: Single large batch: 15 succeeded; 15 failed (50.00% success rate, 0.00% retriable) h2: Validation enabled: Single large batch: 30 succeeded; 0 failed (100.00% success rate) h2: Validation disabled: Multiple small batches: 10 succeeded; 5 failed (66.67% success rate, 0.00% retriable) h2: Validation enabled: Multiple small batches: 15 succeeded; 0 failed (100.00% success rate) h2c: Validation disabled: Sequential requests (slow): 10 succeeded; 0 failed (100.00% success rate) h2c: Validation enabled: Sequential requests (slow): 10 succeeded; 0 failed (100.00% success rate) h2c: Validation disabled: Sequential requests (rapid): 2,483 succeeded; 17 failed (99.32% success rate, 0.00% retriable) h2c: Validation enabled: Sequential requests (rapid): 2,500 succeeded; 0 failed (100.00% success rate) h2c: Validation disabled: Single large batch: 15 succeeded; 15 failed (50.00% success rate, 0.00% retriable) h2c: Validation enabled: Single large batch: 30 succeeded; 0 failed (100.00% success rate) h2c: Validation disabled: Multiple small batches: 10 succeeded; 5 failed (66.67% success rate, 0.00% retriable) h2c: Validation enabled: Multiple small batches: 15 succeeded; 0 failed (100.00% success rate) ``` Additionally, there are two problems: 1. The `h2` test case for rapid sequential tests has a tendency to hang, irrespective of whether stale connection validation is enabled. I'm guessing there's a race condition here that causes the continuation (`PingCommand`, `StaleCheckCommand`, or connection lease callback) to be dropped on the floor. I'm going to submit `TestConnectionClosureRace` as an integration test after all, since even without any additional assertions it's catching a serious bug. 2. This PR does not include the changes from https://github.com/apache/httpcomponents-core/commit/dfa2cd51c038f5f3259d10a5cfba73953245f188 to read all available data from the socket. Without those changes, `StaleCheckCommand` doesn't work properly on plaintext HTTP/1.1 connections: ``` http: Validation disabled: Sequential requests (rapid): 2,489 succeeded; 11 failed (99.56% success rate, 0.44% retriable) http: Validation enabled: Sequential requests (rapid): 2,499 succeeded; 1 failed (99.96% success rate, 0.00% retriable) http: Validation disabled: Single large batch: 15 succeeded; 15 failed (50.00% success rate, 0.00% retriable) http: Validation enabled: Single large batch: 15 succeeded; 15 failed (50.00% success rate, 0.00% retriable) http: Validation disabled: Multiple small batches: 10 succeeded; 5 failed (66.67% success rate, 0.00% retriable) http: Validation enabled: Multiple small batches: 10 succeeded; 5 failed (66.67% success rate, 0.00% retriable) ``` Remember, the contract for `StaleCheckCommand` is that the callback occurs after _all_ pending reads on the connection have been processed, so the caller has to be sure to do that. -- 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: dev-unsubscr...@hc.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
