I think this might explain why I see random integration test failures
on macOS. After your last email, I ran the integration tests in a loop
on Windows and WSL2 and they don't fail, but on my Mac I get random
test failures. `ulimit -n` reports `256` which is way too low, so I'm
experimenting with h
On 2025-07-04 18:59, Ryan Schmitt wrote:
Evidently my JEP380 SocketChannel->Socket adapter is broken on
Windows. If I revert 97703d901 the tests run fine on my Windows
machine across all four Java versions. If you're seeing failures on
master unrelated to 97703d901, something else is up. (Firewa
Evidently my JEP380 SocketChannel->Socket adapter is broken on
Windows. If I revert 97703d901 the tests run fine on my Windows
machine across all four Java versions. If you're seeing failures on
master unrelated to 97703d901, something else is up. (Firewall
settings?)
On Thu, Jul 3, 2025 at 3:07 A
On 2025-07-02 20:55, Ryan Schmitt wrote:
"Stale" means that the remote peer closed the connection but we don't
know it until we try to reuse the connection, right?
Correct. However, this can happen to blocking connections only because
due to the classic i/o inherent design limitations they ca
"Stale" means that the remote peer closed the connection but we don't
know it until we try to reuse the connection, right? Because this is
definitely a problem with the async client. Users are seeing
`ConnectionClosedException` immediately thrown from the `execute`
method, and they're reaching for
On Tue, 2025-07-01 at 11:26 -0700, Ryan Schmitt wrote:
> What is the intended behavior of `setValidateAfterInactivity` on the
> async client with HTTP/1.1 connections? The current implementation
> is:
>
> if (poolEntry.hasConnection()) {
> final ManagedAsyncClientConnection connection =
> pool
