[
https://issues.apache.org/jira/browse/GEODE-7450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16974649#comment-16974649
]
ASF subversion and git services commented on GEODE-7450:
--------------------------------------------------------
Commit 1f4331c7aed76c7476cdcff66d4e29028ff2b943 in geode's branch
refs/heads/feature/GEODE-7450 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1f4331c ]
GEODE-7450 SSL peerAppDataBuffer expansion needs work
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
> Time Spent: 10m
> 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)
