defaulting to unbounded, in order to preserve current behaviour; this will cap the number of connections initiated for a given origin for a pool, which if not shared, will be per-origin; this will include connections from separate option profiles
a pool timeout is defined to checkout a connection when limit is reeached
the change to read/write cancellation-driven timeouts as the default
timeout strategy revealed a performance regression; because these were
built on Timers, which never got unsubscribed, this meant that they were
kept beyond the duration of the request they were created for, and
needlessly got picked up for the next timeout tick.
This was fixed by adding a callback on timer intervals, which
unsubscribes them from the timer group when called; these would then be
activated after the timeout is not needed anymore (request send /
response received), thereby removing the overhead on subsequent
requests.
An additional intervals array is also kept in the connection itself;
timeouts from timers are signalled via socket wait calls, however they
were always resulting in timeouts, even when they shouldn't (ex: expect
timeout and send full response payload as a result), and with the wrong
exception class in some cases. By keeping intervals from its requests
around, and monitoring whether there are relevant request triggers, the
connection can therefore handle a timeout or bail out (so that timers
can fire the correct callback).
when closed, connections are now placed in a place called eden_connections; whenever a connection is matched for, after checking the live connections and finding none, a match is looked in eden connections; the match is accepted **if** the IP is considered fresh (the input is validated in the cache, or input was an ip or in /etc/hosts, or it's an external socket) and, if a TLS connection, the stored TLS session did not expire; if these conditions do not match, the connection is dropped from the eden and a new connection will started instead; this will therefore allow reusing ruby objects, reusing TLS sessions, and still respect the DNs cache
a behaviour has been observed behind a vpn, where when one of the
servers is unresponsive, the switch to the next nameserver wasn't
happening. Part of it was a bug in the timeout handling, but the rest
was actually the switch not happening (i.e. it'd fail on the first
server). This fixes it by switching to the next nammeserver on query
error.
While adding the test, the code to recover from an exhausted HTTP/1.1
connection proved not to be reliable, as it wasn't taking inflight
requests nor update-once keep-alive max requests counters into
account.
This has been fixed by implementing our own test dummy using
webrick.
