Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
1.10.0
-
None
Description
I commented out the first invocation of expandPeerAppData() in NioSslEngine.unwrap() and found that the handling of BufferOverFlowException in that method doesn't always handle increase of the decrypt buffer ("peerAppData") correctly with all cipher suites.
The handling of that exception needs to ensure that it increases the capacity of the peerAppData buffer every time an overflow happens. Repeated overflows should cause the buffer to keep expanding until it's big enough to hold the decrypted data.
If that's done the initial invocation of expandPeerAppData() could be removed, saving us from having to perform calculations that usually aren't necessary.
The exception handling could be something like this:
int newCapacity = (peerAppData.limit() - peerAppData.position()) * 2 + peerAppData.position(); newCapacity = Math.max(newCapacity, peerAppData.capacity() / 2 * 3); peerAppData = bufferPool.expandWriteBufferIfNeeded(TRACKED_RECEIVER, peerAppData, newCapacity); peerAppData.limit(peerAppData.capacity()); break;
I've done informal testing of that change and it seems to work. The test created a cache using 100k socket buffers and did puts using 70k byte-array payloads that were replicated to a second node. TLSv1.2 was used as the SSL protocol. Logging traces that I had in place showed the buffer increasing in capacity with each overflow exception until the buffer was big enough to hold the 70k+ decrypted update messages.
