[
https://issues.apache.org/jira/browse/GEODE-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7450.
---------------------------------------
Fix Version/s: 1.12.0
Resolution: Fixed
> SSL peerAppDataBuffer expansion needs work
> ------------------------------------------
>
> Key: GEODE-7450
> URL: https://issues.apache.org/jira/browse/GEODE-7450
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
> Affects Versions: 1.10.0
> Reporter: Bruce J Schuchardt
> Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> 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)
