[
https://issues.apache.org/jira/browse/GEODE-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975311#comment-16975311
]
ASF subversion and git services commented on GEODE-7450:
--------------------------------------------------------
Commit 05df143224ab07547522e960334007b521babc09 in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=05df143 ]
GEODE-7450 SSL peerAppDataBuffer expansion needs work (#4330)
The expansion logic for the decrypted buffer in NioSslEngine was
expanding the buffer to twice its old capacity and wouldn't go
beyond that. Some ciphers will compress data a lot more than that, so
we need to continually increase available space in the decryption buffer
if the SslEngine reports a BUFFER_OVERFLOW status. The changes in
this commit do that by always doubling the available space in the
decryption buffer in response to a BUFFER_OVERFLOW.
Along with that I found it unnecessary to take preemptive action to
increase the size of the buffer and deleted that code.
> 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)
