Bruce J Schuchardt created GEODE-7450:
-----------------------------------------
Summary: SSL peerAppDataBuffer expansion needs work
Key: GEODE-7450
URL: https://issues.apache.org/jira/browse/GEODE-7450
Project: Geode
Issue Type: Bug
Components: messaging
Reporter: Bruce J Schuchardt
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:
{code:java}
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;
{code}
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.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
