[
https://issues.apache.org/jira/browse/GEODE-8681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17234122#comment-17234122
]
ASF subversion and git services commented on GEODE-8681:
--------------------------------------------------------
Commit 4cedf9ff63952bb2a200ba0f218216a4e2ec272a in geode's branch
refs/heads/master from Ernie Burghardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4cedf9f ]
[BACKPORT] GEODE-8681: peer-to-peer message loss due to sending connection
closi… (#5713)
* GEODE-8681: peer-to-peer message loss due to sending connection closing with
TLS enabled (#5699)
A socket-read could pick up more than one message and a single unwrap()
could decrypt multiple messages.
Normally the engine isn't closed and it reports normal
status from an unwrap() operation, and Connection.processInputBuffer
picks up each message, one by one, from the buffer and dispatches them.
But if the SSLEngine is closed we were ignoring any already-decrypted
data sitting in the unwrapped buffer and instead we were throwing an
SSLException.
(cherry picked from commit 7da8f9b516ac1e2525a1dfc922af7bfb8995f2c6)
Authored-by: Bruce Schuchardt <bschucha...@pivotal.io>
> peer-to-peer message loss due to sending connection closing with TLS enabled
> ----------------------------------------------------------------------------
>
> Key: GEODE-8681
> URL: https://issues.apache.org/jira/browse/GEODE-8681
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
> Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0
> Reporter: Bruce J Schuchardt
> Assignee: Bruce J Schuchardt
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> We have observed message loss when TLS is enabled and a distributed lock is
> released right after sending a message that doesn't require acknowledgement
> if the sending socket is immediately closed. The closing of sockets
> immediately after sending a message is frequently seen in function execution
> threads or server-side application threads that use this pattern:
> {code:java}
> try {
> DistributedSystem.setThreadsSocketPolicy(false);
> acquireDistributedLock(lockName);
> (perform one or more cache operations)
> } finally {
> distLockService.unlock(lockName);
> DistributedSystem.releaseThreadsSockets(); // closes the socket
> }
> {code}
> The fault seems to be in NioSSLEngine.unwrap(), which throws an
> SSLException() if it finds the SSLEngine is closed even though there is valid
> data in its decrypt buffer. It shouldn't throw an exception in that case.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
