+ From discussion with Simone, the dispatched fillInterest.onFail()
needs to occur, so that the AbstractConnection.onReadTimeout() can
handle the close conditions needed by SPDY and WebSocket.
The EndPoint close within onIdleExpired is a race condition with
this onReadTimeout desired behavior.
Introduced LeakDetector and utility classes LeakTrackingConnectionPool
and LeakTrackingByteBufferPool to track resource pool leakages.
Fixed ConnectionPool to be more precise in closing connections when
release() cannot recycle the connection.
Fixed a leak in server's HttpConnection in case a request arrives with
the Connection: close header: a ByteBuffer was allocated but never
released.
Removed code duplications, and also removed method close(),
unnecessary since onClose() was performing the exact same code.
Also reviewed subclasses of IdleTimeout to make sure that they always
call onClose() when they are "closed", to make sure that the timeout
does not fire and that there are no memory leaks (the scheduler
holding a reference to the timeout task, which in turn holds a
reference to the IdleTimeout instance).
work.
Fixed by making sure that we completely decrypt read bytes.
Before the fix, it was possible that we returned after the decryption
of one TLS frame, while another was still present in the
_encryptedBuffer.
This lead to non-clean closes of the connection, which hampered the
capability of session reuse by clients.
Now we decrypt in a loop and only return if there is nothing more
that we can decrypt.
Big refactoring to allow for additional proxy schemes that work at a
lower level than HTTP.
Introduced client-side ConnectionFactory, and binding that to a
HttpDestination, so that connections to that destination will use the
same ConnectionFactory.
The destination's ConnectionFactory is now initialized from the proxy
configuration and the transport, which is now itself a
ConnectionFactory.
The proxy configuration has also changed becoming polymorphic by
introducing a new ProxyConfiguration.Proxy abstract class,
which is implemented as HTTPProxy and can be implemented in future as
SOCKS4Proxy (and possibly others).
These were possible on a busy server, when many new connections are
created, and each triggers read interest: one connection submits the
read interest change, then runs the changes, finds that another
connections is created, runs it, which schedule a read interest
change, and so on.
Now the code is simpler, and while we always offer to the queue,
it may even be faster.
Greg Wilkins
Joakim Erdfelt
Simone Bordet
Mikhail Mazursky