[
https://issues.apache.org/jira/browse/GEODE-8020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17100856#comment-17100856
]
ASF GitHub Bot commented on GEODE-8020:
---------------------------------------
echobravopapa commented on a change in pull request #5048:
URL: https://github.com/apache/geode/pull/5048#discussion_r420837745
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/net/NioSslEngine.java
##########
@@ -398,6 +398,7 @@ public void close(SocketChannel socketChannel) {
} finally {
bufferPool.releaseBuffer(TRACKED_SENDER, myNetData);
bufferPool.releaseBuffer(TRACKED_RECEIVER, peerAppData);
+ myNetData = null;
Review comment:
that's cute, personalized data ;P
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/tcp/MsgStreamerList.java
##########
@@ -63,25 +63,16 @@ public int writeMessage() throws IOException {
for (MsgStreamer streamer : this.streamers) {
if (ex != null) {
streamer.release();
- // TODO: shouldn't we call continue here?
- // It seems wrong to call writeMessage on a streamer we have just
released.
- // But why do we call release on a streamer when we had an exception
on one
- // of the previous streamer?
- // release clears the direct bb and returns it to the pool but leaves
- // it has the "buffer". THen we call writeMessage and it will use
"buffer"
- // that has also been returned to the pool.
- // I think we only have a MsgStreamerList when a DS has a mix of
versions
- // which usually is just during a rolling upgrade so that might be why
we
- // haven't noticed this causing a bug.
- }
- try {
- result += streamer.writeMessage();
- // if there is an exception we need to finish the
- // loop and release the other streamer's buffers
- } catch (RuntimeException e) {
- ex = e;
- } catch (IOException e) {
- ioex = e;
+ } else {
Review comment:
thx for removing all those crufty comments
##########
File path:
geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java
##########
@@ -69,7 +74,8 @@ public BufferPool(DMStats stats) {
/**
* use direct ByteBuffers instead of heap ByteBuffers for NIO operations
*/
- public static final boolean useDirectBuffers =
!Boolean.getBoolean("p2p.nodirectBuffers");
+ public static final boolean useDirectBuffers =
!(Boolean.getBoolean("p2p.nodirectBuffers")
+ || Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX + "noDirectBuffers"));
Review comment:
is the GF prefixed version of the property need to be exposed/documented?
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> buffer corruption in SSL communications
> ---------------------------------------
>
> Key: GEODE-8020
> URL: https://issues.apache.org/jira/browse/GEODE-8020
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
> Reporter: Bruce J Schuchardt
> Assignee: Bruce J Schuchardt
> Priority: Major
>
> When running an application with SSL enabled I ran into a hang with a lost
> message. The sender had a 15 second ack-wait warning pointing to another
> server in the cluster. That server had this in its log file at the time the
> message would have been processed:
> {noformat}
> [info 2020/04/21 11:22:39.437 PDT <P2P message reader for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599)<ec><v1>:41003
> unshared ordered uid=354 dom #2 port=55262> tid=0xad] P2P message
> reader@2580db5f io exception for
> rs-bschuchardt-1053-hydra-client-1(bridgegemfire4_host1_12599:12599)<ec><v1>:41003@354(GEODE
> 1.10.0)
> javax.net.ssl.SSLException: bad record MAC
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:214)
> at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1728)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:986)
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:912)
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:782)
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
> at
> org.apache.geode.internal.net.NioSslEngine.unwrap(NioSslEngine.java:275)
> at
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2894)
> at
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1745)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1577)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: javax.crypto.BadPaddingException: bad record MAC
> at sun.security.ssl.InputRecord.decrypt(InputRecord.java:219)
> at
> sun.security.ssl.EngineInputRecord.decrypt(EngineInputRecord.java:177)
> at sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:979)
> ... 10 more
> {noformat}
> I bisected to see when this problem was introduced and found it was this
> commit:
> {noformat}
> commit 418d929e3e03185cd6330c828c9b9ed395a76d4b
> Author: Mario Ivanac <48509724+miva...@users.noreply.github.com>
> Date: Fri Nov 1 20:28:57 2019 +0100
> GEODE-6661: Fixed use of Direct and Non-Direct buffers (#4267)
> - Fixed use of Direct and Non-Direct buffers
> {noformat}
> That commit modified the NioSSLEngine to use a "direct" byte buffer instead
> of a heap byte buffer. If I revert that one part of the PR the test works
> okay.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
