The problem was that release uses ByteBuffer.isDirect() to know where
to put the released buffer, and Tagged was always creating heap buffers.
This leads to a very high miss ratio in the pool, which causes OOME in
some tests.
+ Making use of LeakTrackingByteBufferPool more consistent
+ Using MappedByteBufferPool.Tagged where appropriate in test cases
+ Adding leak count tracking to LeakDetector
+ Adding leak count tracking to LeakTrackingByteBufferPool
+ Renaming websocket LeakTrackingBufferPool to
LeakTrackingBufferPoolRule to reflect junit @Rule usage
+ Making websocket LeakTrackingBufferPoolRule always use
MappedByteBufferPool.Tagged
+ Fixed various grammar concerns
Added the concept of UpgradeFrom and UpgradeTo connections that support
transferring a buffer with content before opening new connection.
Aded EndPoint.update method as utility
Fixed WriteFlusher to distinguish between a flush that consumes all content and returns false, from one
that consumes all content and returns true.
If false is returned, the flusher needs to remain in pending so encrypted buffers can be flushed.
Fixed IllegalStateException by handling NEED_UNWRAP for the CLOSED
state in fill().
The EOFException does not seem to be an issue with the client.
Also removed an unneeded catch block and an empty if statement.
+ 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).
Greg Wilkins
Simone Bordet
Joakim Erdfelt
Greg Wilkins