[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528480#comment-17528480 ] Geode Integration commented on GEODE-6183: -- Seen in [windows-core-integration-test-openjdk8 #313|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-core-integration-test-openjdk8/builds/313] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1123/test-results/integrationTest/1650932064/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1123/test-artifacts/1650932064/windows-coreintegrationtestfiles-openjdk8-1.15.0-build.1123.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528479#comment-17528479
]
Geode Integration commented on GEODE-10217:
---
Seen in [unit-test-openjdk8
#319|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/unit-test-openjdk8/builds/319]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1124/test-results/test/1650992503/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1124/test-artifacts/1650992503/unittestfiles-openjdk8-1.15.0-build.1124.tgz].
> NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes
> multiple test failures
> ---
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> The below stack traces were seen in the unit-test-openjdk8 job in the
> pipeline. In addition to the two failures shown, multiple other failures due
> to {{NoClassDefFoundError}} for {{ThreadLocalRandom}} were also present.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebud
[jira] [Updated] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10260: --- Labels: needsTriage pull-request-available (was: needsTriage) > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage, pull-request-available > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-10260: --- Assignee: Jinmei Liao > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
[ https://issues.apache.org/jira/browse/GEODE-10260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10260: -- Labels: needsTriage (was: ) > FilterProfile of a peer server would sometimes miss a CQ when server > initializes > > > Key: GEODE-10260 > URL: https://issues.apache.org/jira/browse/GEODE-10260 > Project: Geode > Issue Type: Bug >Reporter: Jinmei Liao >Priority: Major > Labels: needsTriage > > When server2 initializes at the same time as client register CQ while > connected to server1, when below sequence happened, server2 will have a wrong > idea what cq server1 should serve: > 1. server2 creates the partitioned region and sends a CreateRegionMessage to > server1 > 2. server1 process this message and adds server2 to its profile list > 3. server1 reply to server2 with a CreateRegionReplyMessage > 4. At thee same time server1 does register cq locally and send a REGISTER_CQ > message to server2 > 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache > profile yet, so it wants to save the message to the "to_be_processed" queue, > but get stuck there. > 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now > has server1's cache profile, processed the message and then processed > everything in the "to_be_processed" queue. > 7. Now #5 gets unstuck and continues, adds the message to the queue, but the > queue is never processed again, so now in server2's viewpoint, server1 is not > serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10260) FilterProfile of a peer server would sometimes miss a CQ when server initializes
Jinmei Liao created GEODE-10260: --- Summary: FilterProfile of a peer server would sometimes miss a CQ when server initializes Key: GEODE-10260 URL: https://issues.apache.org/jira/browse/GEODE-10260 Project: Geode Issue Type: Bug Reporter: Jinmei Liao When server2 initializes at the same time as client register CQ while connected to server1, when below sequence happened, server2 will have a wrong idea what cq server1 should serve: 1. server2 creates the partitioned region and sends a CreateRegionMessage to server1 2. server1 process this message and adds server2 to its profile list 3. server1 reply to server2 with a CreateRegionReplyMessage 4. At thee same time server1 does register cq locally and send a REGISTER_CQ message to server2 5. REGISTER_CQ message reaches server2, server2 doesn't have server1's cache profile yet, so it wants to save the message to the "to_be_processed" queue, but get stuck there. 6. meanwhile, the CreateRegionReplyMessage in #3 reaches server2, server2 now has server1's cache profile, processed the message and then processed everything in the "to_be_processed" queue. 7. Now #5 gets unstuck and continues, adds the message to the queue, but the queue is never processed again, so now in server2's viewpoint, server1 is not serving that CQ. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-10122: - Affects Version/s: 1.14.0 1.13.0 1.12.0 (was: 1.13.7) (was: 1.14.3) (was: 1.12.9) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.13.9, 1.14.5, 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-10122: - Affects Version/s: 1.12.9 > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.12.9, 1.13.7, 1.14.3, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.13.9, 1.14.5, 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-10122: - Fix Version/s: 1.13.9 1.14.5 > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.13.9, 1.14.5, 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528444#comment-17528444 ] ASF subversion and git services commented on GEODE-10122: - Commit 6b9320830724dcab8fb1ed3ad3211c4dfc5bf5b5 in geode's branch refs/heads/support/1.13 from Bill Burcham [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6b93208307 ] GEODE-10122: P2P Messaging Handles TLS KeyUpdate Message (#7449) (#7615) (#7625) * Key expiration works for TLSv1.3 and GCM-based ciphers * TLS KeyUpdate messages are processed correctly * Removed dependencies on: Mockito 4, JUnit 5, GeodeParamsRunner (cherry picked from commit d2535394a82ac5faf10f004f4e3c15f756f7b177) (cherry picked from commit 07c08e95025ff955c9b361db4b97902ce722be81) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528426#comment-17528426 ] ASF subversion and git services commented on GEODE-10122: - Commit 07c08e95025ff955c9b361db4b97902ce722be81 in geode's branch refs/heads/support/1.14 from Bill Burcham [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07c08e9502 ] GEODE-10122: P2P Messaging Handles TLS KeyUpdate Message (#7449) (#7615) * Key expiration works for TLSv1.3 and GCM-based ciphers * TLS KeyUpdate messages are processed correctly * Removed dependencies on: Mockito 4, JUnit 5, GeodeParamsRunner (cherry picked from commit d2535394a82ac5faf10f004f4e3c15f756f7b177) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.15.0 > > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10039: Fix Version/s: 1.15.0 > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-8506) BufferPool returns byte buffers that may be much larger than requested
[ https://issues.apache.org/jira/browse/GEODE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Burcham updated GEODE-8506: Description: BufferPool manages several pools of direct-memory ByteBuffers. When asked for a ByteBuffer of size X you may receive a buffer that is any size greater than or equal to X. For users of this pool this is unexpected behavior and is causing some trouble. MsgStreamer, for instance, performs message "chunking" based on the size of a socket's buffer size. It requests a byte buffer of that size and then fills it over and over again with message chunks to be written to the socket. But it does this based on the buffer's capacity, which may be much larger than the expected buffer size. This results in incorrect chunking and requires larger buffers in the receiver of these message chunks. BufferPool should always return a buffer that has exactly the requested capacity. It could be a _slice_ of a pooled buffer, for instance. That would let it hand out a larger buffer while not confusing the code that requested the buffer. was: BufferPool manages several pools of direct-memory ByteBuffers. When asked for a ByteBuffer of size X you may receive a buffer that is any size greater than or equal to X. For users of this pool this is unexpected behavior and is causing some trouble. MessageStreamer, for instance, performs message "chunking" based on the size of a socket's buffer size. It requests a byte buffer of that size and then fills it over and over again with message chunks to be written to the socket. But it does this based on the buffer's capacity, which may be much larger than the expected buffer size. This results in incorrect chunking and requires larger buffers in the receiver of these message chunks. BufferPool should always return a buffer that has exactly the requested capacity. It could be a _slice_ of a pooled buffer, for instance. That would let it hand out a larger buffer while not confusing the code that requested the buffer. > BufferPool returns byte buffers that may be much larger than requested > -- > > Key: GEODE-8506 > URL: https://issues.apache.org/jira/browse/GEODE-8506 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.13.1, 1.14.0 > > > BufferPool manages several pools of direct-memory ByteBuffers. When asked > for a ByteBuffer of size X you may receive a buffer that is any size greater > than or equal to X. For users of this pool this is unexpected behavior and > is causing some trouble. > MsgStreamer, for instance, performs message "chunking" based on the size of a > socket's buffer size. It requests a byte buffer of that size and then fills > it over and over again with message chunks to be written to the socket. But > it does this based on the buffer's capacity, which may be much larger than > the expected buffer size. This results in incorrect chunking and requires > larger buffers in the receiver of these message chunks. > BufferPool should always return a buffer that has exactly the requested > capacity. It could be a _slice_ of a pooled buffer, for instance. That > would let it hand out a larger buffer while not confusing the code that > requested the buffer. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10256) HttpSessionListener is not working
[
https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528391#comment-17528391
]
Jens Deppe commented on GEODE-10256:
Hello [~masaki.yamakawa]! Thank you for this ticket and the analysis.
So the relevant code is here in
[SessionExpirationCacheListener|https://github.com/apache/geode/blob/a5bd36f9fa787d3a71c6e6efafed5a7b0fe52d2b/extensions/geode-modules/src/main/java/org/apache/geode/modules/session/catalina/callback/SessionExpirationCacheListener.java].
The essence of what you're seeing is coming from the {{afterDestroy}} method
and the if-else block there. So the first part of the {{if}} handles a destroy
triggered by expiry on the client. The second part should handle an expiry from
the server. However the caveat is that you need to set the system parameter,
indicated in the comment there,
({{{}gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK{}}}), on the server. That should
then allow any listeners to fire even when receiving a destroy from the server.
The comment does indicate that this is only relevant for {{PROXY}} (empty)
regions but I think that may be incorrect. Please would you try this change and
let us know the outcome.
> HttpSessionListener is not working
> --
>
> Key: GEODE-10256
> URL: https://issues.apache.org/jira/browse/GEODE-10256
> Project: Geode
> Issue Type: Bug
> Components: expiration, http session
>Affects Versions: 1.15.0
>Reporter: Masaki Yamakawa
>Priority: Minor
> Labels: pull-request-available
>
> I am using "HTTP Session Management Module for Tomcat".
> When data managed in a session expires, I want to use HttpSessionListener to
> handle the deletion of the associated data.
> However, the sessionDestroyed method is not called when the session expires.
> When session expiration is enabled,
> org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers
> and Clients.
> And when expiration occurs, ExpirationAction.DESTROY is executed.
> DESTROY is executed on all CacheServers and clients at about the same time,
> and the result of the deletion on the CacheServer is propagated to clients.
> At that time, the operation type of the message sent from the CacheServer to
> clients is DESTROY.
> SessionExpirationCacheListener is set in the client, but
> HttpSessionListener#sessionDestroyed will only be executed if
> Operation.EXPIRE_DESTROY.
> HttpSessionListener#sessionDestroyed is executed if the expiration process is
> run first on the client side, but HttpSessionListener#sessionDestroyed is
> executed if the CacheServer's DESTROY event is received first.
> sessionDestroyed is not executed.
> We should send the EXPIRE_DESTROY event from CacheServer, but I think this
> has a big impact.
> Therefore, I have introduced a Java system property that delays expiration
> processing on the CacheServer.
> By setting this, HttpSessionListener#sessionDestroyed will surely be executed
> by delaying the server-side expiration processing rather than the client's
> expiration processing.
> Also, if this system property is not set, the behavior will be the same as
> the current.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528380#comment-17528380
]
Mark Hanson commented on GEODE-10228:
-
Awaiting PR review approvals at this point. The initial code change was put in
as well as a bunch of reviewer comment changes.
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-10248.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccess
[jira] [Commented] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528379#comment-17528379
]
Mark Hanson commented on GEODE-10248:
-
The core problem was that the test was outputting a string the suspicious
string parser didn't like. So I added a special case for "Management Request: "
followed by packet data, which is what that log statement outputs.
I think we should not be logging like this at the info level.
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
>
[jira] [Commented] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528371#comment-17528371 ] Donal Evans commented on GEODE-10258: - This is a test issue caused by an await being used with a slightly incorrect type of assertion. > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-10106) CI Failure: CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer
[
https://issues.apache.org/jira/browse/GEODE-10106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao reopened GEODE-10106:
-
This happened on last weekend's regression runs as well. This stack trace
showed up in the logs:
{quote}
system.log contains java.lang.NullPointerException
at
org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:866)
at
org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1466)
at
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
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)
{quote}
> CI Failure: CacheClientNotifierDUnitTest >
> testNormalClient2MultipleCacheServer
> ---
>
> Key: GEODE-10106
> URL: https://issues.apache.org/jira/browse/GEODE-10106
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1382]
> {noformat}
> CacheClientNotifierDUnitTest > testNormalClient2MultipleCacheServer FAILED
> 11:49:39java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 11:49:39Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 11:49:39
> ---
> 11:49:39Found suspect string in 'dunit_suspect-vm4.log' at line 431
> 11:49:39
> 11:49:39[error 2022/03/05 19:49:36.075 UTC
> tid=55] Error in
> redundancy satisfier
> 11:49:39java.lang.NullPointerException
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl.recoverPrimary(QueueManagerImpl.java:856)
> 11:49:39 at
> org.apache.geode.cache.client.internal.QueueManagerImpl$RedundancySatisfierTask.run2(QueueManagerImpl.java:1454)
> 11:49:39 at
> org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1340)
> 11:49:39 at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 11:49:39 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> 11:49:39 at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 11:49:39 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 11:49:39 at java.lang.Thread.run(Thread.java:750)
> 11:49:39at org.junit.Assert.fail(Assert.java:89)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> 11:49:39at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> 11:49:39at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> 11:49:39at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 11:49:39at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 11:49:39at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 11:49:39at java.lang.reflect.Method.invoke(Method.java:498)
> 11:49:39at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> 11:49:39at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 11:49:39at
> org.junit.runners
[jira] [Updated] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10258: --- Labels: needsTriage pull-request-available (was: needsTriage) > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-10066.
---
Resolution: Fixed
Not back porting to older releases. Fix misconfigured locator or update to
Geode 1.15.
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.12.10, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
> org.apache.geode.int
[jira] [Resolved] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett resolved GEODE-9991.
--
Resolution: Fixed
Not back porting to older releases due to complexity of upgrading the patches.
Users should upgrade to Geode 1.15 using the documented steps in this ticket.
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available, ssl
> Fix For: 1.15.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[ https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528322#comment-17528322 ] Jacob Barrett commented on GEODE-9991: -- h1. Geode Upgrade Methods for 1.15.0 h1. Preface Migration steps are only required if ssl-endpoint-identification-enabled=true. All other upgrades are allowed without migration steps. Migration is required due to a bug introduced that causes Geode to ignore the configured ssl-protocols and fall back to the JVM defaults, which can result in the client side being configured with SSLv2Hello and the server to deny it. With this mismatch in protocol configuration the member can fail to establish P2P connections to other members of the cluster. Two new properties are introduced in this version to configure the server and client side of the P2P connections separately, ssl-server-protocols and ssl-client-protocols respectively. h1. Upgrading Geode You can upgrade Geode to 1.15.0, with or without upgrading the JVM, under these conditions. h2. From 1.14.0-1.14.4, 1.13.0-1.13.8, 1.12.1-1.12.9 If ssl-protocols is explicitly set but does not include SSLv2Hello, for example “TLSv1.2,TLSv1.1”, then goto [Upgrade With New Properties|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.modyy795d4pz]. If ssl-protocols explicitly includes SSLv2Hello, for example “TLSv1.2,SSLv2Hello”, then goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. If ssl-protocols is unset or set to “any”, then goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h2. From 1.12.0, 1.11.0, 1.10.0, 1.9.2, 1.8.0 No special considerations required, goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h2. From Other Versions These are untested and should not be attempted in production. h1. Upgrading JVM Only If you are upgrading the JVM only, from a Java 1.8 version prior to TLS 1.3 support you may also need to upgrade Geode. TLS 1.3 was backported to different versions of Java 1.8 by various vendors. OpenJDK backport version is 1.8.0_271. Oracle JDK backport version is 1.8.0_261. For other vendors please refer to their documentation. h2. From 1.14.0-1.14.4, 1.13.0-1.13.8, 1.12.1-1.12.9 You cannot upgrade the JVM without upgrading Geode to 1.15.0. This can be done in a single restart. Goto [Upgrade With New Properties|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.modyy795d4pz]. h2. For 1.12.0, 1.12.0, 1.11.0, 1.10.0, 1.9.2, 1.8.0 No special considerations required, goto [Upgrade Without Migration|https://docs.google.com/document/d/1YKDRYlZV8vfGyJCS2WlLhUAegUngxHV03HsIyhNLwvg/edit#heading=h.5b7id4y6hflk]. h1. Upgrade Without Migration You have nothing to fear, go ahead and upgrade like normal. h1. Upgrade With New Properties Use the new ssl-client-protocols and ssl-server-protocols properties to configure the client and server side of the SSL connection independently. You will need to add SSLv2Hello to the ssl-server-protocols to account for the misconfiguration of the older members in the cluster. # Shutdown member. # Install new Geode. # Optionally install new Java JDK. # Eliminate security property ssl-protocols from the server’s configuration. # Add security property ssl-client-protocols with the explicit value(s) previously defined in ssl-protocols. For example, if ssl-protocols=TLSv1.2 then ssl-client-protocols=TLSv1.2. # Add security property ssl-server-protocols with the explicit value(s) previously defined in ssl-protocols plus “SSLv2Hello”. For example, if ssl-protocols=TLSv1.2 then ssl-server-protocols=TLSv1.2,SSLv2Hello. # Start member. # Verify successful cluster join. # Repeat from step 1 for the next member. Optionally, after the migration is complete you may restore your original ssl-protocols property and restart all your members to eliminate the SSLv2Hello protocol support from the server side sockets. > SSL protocol and cipher preferences are ignored when endpoint verification is > enabled. > -- > > Key: GEODE-9991 > URL: https://issues.apache.org/jira/browse/GEODE-9991 > Project: Geode > Issue Type: Bug > Components: core, security >Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: blocks-1.15.0, pull-request-available, ssl > Fix For: 1.15.0 > > > When SSL endpoint verif
[jira] [Assigned] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10258: --- Assignee: Donal Evans > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119) > at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31) > at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17528282#comment-17528282
]
ASF subversion and git services commented on GEODE-10248:
-
Commit 718aafeb35906c6f25dac0bf266a2cdb962bd37a in geode's branch
refs/heads/develop from mhansonp
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=718aafeb35 ]
GEODE-10248: Adding a new Suspicious Strings exception (#7612)
for Management Requests that get logged and a test
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatfor
[jira] [Updated] (GEODE-10215) WAN replication not working after re-creating the partitioned region
[
https://issues.apache.org/jira/browse/GEODE-10215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10215:
---
Labels: pull-request-available (was: )
> WAN replication not working after re-creating the partitioned region
>
>
> Key: GEODE-10215
> URL: https://issues.apache.org/jira/browse/GEODE-10215
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
>
> Steps to reproduce the issue:
> Start multi-site with at least 3 servers on each site. If there are less than
> three servers then issue will not reproduce.
> Configuration site 1:
> {code:java}
> create disk-store --name=queue_disk_store --dir=ds2
> create gateway-sender -id="remote_site_2" --parallel="true"
> --remote-distributed-system-id="1" -enable-persistence=true
> --disk-store-name=queue_disk_store
> create disk-store --name=data_disk_store --dir=ds1
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #Configure the remote site 2 with the region and the gateway-receiver
> #Run some traffic so that all buckets are created and data is replicated to
> the other site
> alter region --name=/example-region --gateway-sender-id=""
> destroy region --name=/example-region
> create region --name=example-region --type=PARTITION_PERSISTENT
> --gateway-sender-id="remote_site_2" --disk-store=data_disk_store
> --total-num-buckets=1103 --redundant-copies=1 --enable-synchronous-disk=false
> #run traffic to see that some data is not replicated to the remote site 2
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
