[jira] [Updated] (GEODE-10189) Errors encountered during Apache Geode upgrade
[ https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10189: -- Labels: needsTriage (was: ) > Errors encountered during Apache Geode upgrade > -- > > Key: GEODE-10189 > URL: https://issues.apache.org/jira/browse/GEODE-10189 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.1 >Reporter: Swetha Sudheesh >Priority: Major > Labels: needsTriage > > We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1* > version to avoid any vulnerabilities. We also added all the dependencies > mentioned in the Maven with the latest versions. We faced few issues such as > the one described below: > > Exception in thread "Locator" *java.lang.ExceptionInInitializerError* > at > org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155) > at > org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114) > at > org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152) > at > org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132) > at > org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011) > at > org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282) > at > org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746) > at > org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392) > at > org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716) > > Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the > wrong class: UUID* > at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101) > at > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167) > ... 17 more > Please let us know why we are encountering this error and how can it be > resolved? Also let us know the right dependencies that need to be added for > Apache Geode 1.14.1 upgrade. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10189) Errors encountered during Apache Geode upgrade
Swetha Sudheesh created GEODE-10189: --- Summary: Errors encountered during Apache Geode upgrade Key: GEODE-10189 URL: https://issues.apache.org/jira/browse/GEODE-10189 Project: Geode Issue Type: Bug Affects Versions: 1.14.1 Reporter: Swetha Sudheesh We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1* version to avoid any vulnerabilities. We also added all the dependencies mentioned in the Maven with the latest versions. We faced few issues such as the one described below: Exception in thread "Locator" *java.lang.ExceptionInInitializerError* at org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155) at org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114) at org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152) at org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219) at org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464) at org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497) at org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326) at org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756) at org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132) at org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011) at org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282) at org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746) at org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392) at org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716) Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the wrong class: UUID* at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101) at org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167) ... 17 more Please let us know why we are encountering this error and how can it be resolved? Also let us know the right dependencies that need to be added for Apache Geode 1.14.1 upgrade. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9298) Remove concourse deprecation warnings
[ https://issues.apache.org/jira/browse/GEODE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514014#comment-17514014 ] ASF subversion and git services commented on GEODE-9298: Commit 483e54cb9c34d4a5f325e72c7a00aed16303c88c in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=483e54c ] GEODE-9298: remove concourse deprecation warnings (cherry picked from commit d7cfc506a69680f90ab1a91c226a227f029d5ad1) > Remove concourse deprecation warnings > - > > Key: GEODE-9298 > URL: https://issues.apache.org/jira/browse/GEODE-9298 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > Concourse is warning of several deprecated functions and names. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514019#comment-17514019 ] ASF subversion and git services commented on GEODE-10179: - Commit 7e18d73c478853c5d8b78c5b2c0b8124b036c493 in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7e18d73 ] [1.13] GEODE-10179: Bump jackson-databind from 2.10.5.1 to 2.12.6.1 (#7503) fixes https://github.com/FasterXML/jackson-databind/issues/2816 > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514021#comment-17514021 ] ASF subversion and git services commented on GEODE-10179: - Commit 36d9260d8180f4a83c95f723600d556fb2dc02d8 in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=36d9260 ] GEODE-10179: Bump jackson-databind from 2.10.5.1 to 2.12.6.1 (#7506) fixes https://github.com/FasterXML/jackson-databind/issues/2816 > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514022#comment-17514022 ] ASF subversion and git services commented on GEODE-10179: - Commit 3f626064c37b885662e1dfd4222b5511caf3307f in geode's branch refs/heads/support/1.14 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f62606 ] GEODE-10179: Bump jackson-databind to 2.12.6.1 (#7501) fixes https://github.com/FasterXML/jackson-databind/issues/2816 > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10179) bump jackson-databind to recommended version
[ https://issues.apache.org/jira/browse/GEODE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514025#comment-17514025 ] ASF subversion and git services commented on GEODE-10179: - Commit 41844a5128f94cba6e27a1fdb0184db35a3f36ac in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=41844a5 ] GEODE-10179: Bump jackson-databind to 2.13.2.1 (#7500) Geode endeavors to update to the latest version of 3rd-party dependencies on develop wherever possible. Doing so increases the shelf life of releases and increases security and reliability. Doing so regularly makes the occasional hiccups this can cause easier to pinpoint and address. This bump of jackson-databind from 2.13.2 to micropatch 2.13.2.1 is a little clunkly and once 2.13.3 or 2.14.0 is available, this should first be reverted... > bump jackson-databind to recommended version > > > Key: GEODE-10179 > URL: https://issues.apache.org/jira/browse/GEODE-10179 > Project: Geode > Issue Type: Task >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > recommend getting to 2.13.2.1 for develop or 2.12.6.1 for support branches -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9298) Remove concourse deprecation warnings
[ https://issues.apache.org/jira/browse/GEODE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514027#comment-17514027 ] ASF subversion and git services commented on GEODE-9298: Commit ca4197900bc913d835db5d6ffd16bc653a010a13 in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ca41979 ] GEODE-9298: remove concourse deprecation warnings (cherry picked from commit d7cfc506a69680f90ab1a91c226a227f029d5ad1) > Remove concourse deprecation warnings > - > > Key: GEODE-9298 > URL: https://issues.apache.org/jira/browse/GEODE-9298 > Project: Geode > Issue Type: Improvement > Components: ci >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0 > > > Concourse is warning of several deprecated functions and names. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10190) Improve runtime of some Redis integration tests
Jens Deppe created GEODE-10190: -- Summary: Improve runtime of some Redis integration tests Key: GEODE-10190 URL: https://issues.apache.org/jira/browse/GEODE-10190 Project: Geode Issue Type: Improvement Components: redis Reporter: Jens Deppe >From Darrel: _I’m doing some refactoring of the ResourceManager and my pr’s integration tests are timing out after running for 45 minutes. Normally integration tests take 18 minutes. When looking at whats tests took a long time I see that AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time it was run. On my laptop I see it run in 2.75 minutes. Another test method I see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These two methods are run twice so that adds up to 30 minutes in just two test methods so I think that is the cause of the timeout. Both of these do concurrency. Any ideas about this? Do you think my refactoring broke something or did I just get a bad run of these tests?_ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-10190: -- Assignee: Jens Deppe > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10190: --- Labels: pull-request-available (was: ) > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10058) Remove Defunct NetCore and C-Bindings from geode-native repo and CI
[ https://issues.apache.org/jira/browse/GEODE-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514171#comment-17514171 ] ASF GitHub Bot commented on GEODE-10058: mmartell closed pull request #949: URL: https://github.com/apache/geode-native/pull/949 -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove Defunct NetCore and C-Bindings from geode-native repo and CI > --- > > Key: GEODE-10058 > URL: https://issues.apache.org/jira/browse/GEODE-10058 > Project: Geode > Issue Type: Task >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This project is being replaced by a pure C# client for .NET Core. > Also, move the SessionState code to a new branch since it's not throw away > code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10166. - Fix Version/s: 1.15.0 Resolution: Fixed > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514190#comment-17514190 ] ASF subversion and git services commented on GEODE-10166: - Commit d8e010d572cef91ec0d821a3db2839cd252fbeec in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d8e010d ] GEODE-10166: Move tests to correct directory (#7491) - Rename InternalCacheForClientAccessDUnitTest -> InternalCacheForClientAccessDistributedTest - Move InternalCacheForClientAccessDistributedTest to geode-core module - Remove spurious parameterization from InternalCacheForClientAccessDistributedTest - Rename NestedQueryClassCastExceptionFailureDUnitTest -> NestedQueryClassCastExceptionFailureDistributedTest - Move NestedQueryClassCastExceptionFailureDistributedTest to geode-core module, change package to cache.query.dunit - Rename RebalanceCommandDistributesTest to RelanaceCommandAcceptanceTest - Move RebalanceCommandAcceptanceTest to geode-assembly module acceptanceTest directory as it requires that GEODE_HOME is set - Remove files from sanctioned-geode-dunit-serializables.txt Authored-by: Donal Evans > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10125) Refactor Redis to Use Public DataSerializable Framework
[ https://issues.apache.org/jira/browse/GEODE-10125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10125: --- Labels: pull-request-available (was: ) > Refactor Redis to Use Public DataSerializable Framework > - > > Key: GEODE-10125 > URL: https://issues.apache.org/jira/browse/GEODE-10125 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Refactor Redis to use the public DataSerializable framework instead of the > DataSerializableFixedId serialization framework. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10058) Remove Defunct NetCore and C-Bindings from geode-native repo and CI
[ https://issues.apache.org/jira/browse/GEODE-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514192#comment-17514192 ] ASF GitHub Bot commented on GEODE-10058: lgtm-com[bot] commented on pull request #950: URL: https://github.com/apache/geode-native/pull/950#issuecomment-1082126444 This pull request **fixes 4 alerts** when merging 9cc02558a27b9f99ba6cfa4724f87d597d3b0523 into 4b2f2462a3bae783cb3e03e3186a58707945fa10 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-8eae0551df9aad51896fd3c3f3dfcb4560dc59bb) **fixed alerts:** * 4 for Dereferenced variable may be null -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove Defunct NetCore and C-Bindings from geode-native repo and CI > --- > > Key: GEODE-10058 > URL: https://issues.apache.org/jira/browse/GEODE-10058 > Project: Geode > Issue Type: Task >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This project is being replaced by a pure C# client for .NET Core. > Also, move the SessionState code to a new branch since it's not throw away > code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514201#comment-17514201
]
ASF subversion and git services commented on GEODE-10119:
-
Commit fef6b163919db5f25db19ae5a9dc5b310ebcdace in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fef6b16 ]
GEODE-10119: Handle SSLHandshakeException on JDK17 (#7475)
PROBLEM
On JDK 17, `SslSocket.startHandshake()` can throw
`SSLHandshakeException` in circumstances where JDK 8 and 11 would throw
`SocketException`.
`SocketCreator.configureClientSSLSocket()` catches this exception, logs
it as fatal, and rethrows it.
`ConnectionFactoryImpl.createClientToServerConnection()` then catches it
and logs it as a warning.
This results in lots of warn/fatal log entries for relatively benign
occurrences that, on JDK 8 and 11, would result in debug entries.
Also, `WANSSLDUnitTest.testSenderSSLReceiverNoSSL()` fails when it sees these
unrecognized entries in the log.
SOLUTION
Change `SocketCreator` and `ConnectionFactoryImpl` to recognize when an
`SSLHandshapeException` describes the kind of problem that would have
thrown a `SocketException` on JDK8/11. If so, treat it the same as a
`SocketException`. If not, treat it as a more serious
`SSLHandshakeException`.
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> 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-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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)
>
[jira] [Resolved] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery resolved GEODE-10119.
Fix Version/s: 1.15.0
Resolution: Fixed
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> 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-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
>
[jira] [Closed] (GEODE-10119) Handle SslSocket throwing SSLHandshakeException on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery closed GEODE-10119.
--
> Handle SslSocket throwing SSLHandshakeException on JDK 17
> -
>
> Key: GEODE-10119
> URL: https://issues.apache.org/jira/browse/GEODE-10119
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: Java17, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In some circumstances, on JDK 17 {{SslSocket}} throws
> {{SSLHandshakeException}}, where on JDK 8 and 11 it would throw
> {{SocketException}}.
> {{SocketCreator.configureClientSSLSocket()}} handles
> {{SSLHandshakeException}} and {{SocketException}} differently:
> - It catches {{SSLHandshakeException}}, logs it as fatal, and rethrows it.
> - It does not catch {{SocketException}}.
> The new "fatal" log entry on JDK 17 causes
> {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} to fail.
> This may be simply a test issue. If so, the fix is to configure the test to
> ignore this new exception.
> But possibly the product's error handling needs to be changed to account for
> {{SslSocket}} throwing {{SSLHandshakeException}}.
> Example {{WANSSLDUnitTest.testSenderSSLReceiverNoSSL()}} test failure on JDK
> 17:
> {noformat}
> 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-vm4.log' at line 548
> [fatal 2022/03/10 01:29:50.162 UTC
> tid=144] Problem forming SSL connection to
> dale-dunit.c.apachegeode-ci.internal/10.128.0.33[28386].
> javax.net.ssl.SSLHandshakeException: Remote host terminated the handshake
> at
> java.base/sun.security.ssl.SSLSocketImpl.handleEOF(SSLSocketImpl.java:1709)
> at
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1508)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1415)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:450)
> at
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:421)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:591)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpSocketCreatorImpl.connect(TcpSocketCreatorImpl.java:59)
> at
> org.apache.geode.distributed.internal.tcpserver.ClientSocketCreatorImpl.connect(ClientSocketCreatorImpl.java:54)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:94)
> at
> org.apache.geode.cache.client.internal.ConnectionConnector.connectClientToServer(ConnectionConnector.java:75)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:120)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:243)
> 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:481)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.serial.RemoteSerialGatewaySenderEventProcessor.initializeEventDispatcher(RemoteSerialGatewaySenderEventProcessor.java:45)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1107)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:195)
> Suppressed: java.net.SocketException: Broken pipe
> at
> java.base/sun.nio.ch.NioSocketImpl.implWrite(NioSocketImpl.java:420)
> at
> java.base/sun.nio.ch.NioSocketImpl.write(NioSocketImpl
[jira] [Commented] (GEODE-10182) A null check due to detecting read conflict is no longer necessary
[ https://issues.apache.org/jira/browse/GEODE-10182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514205#comment-17514205 ] ASF subversion and git services commented on GEODE-10182: - Commit b5d69172751bc8b5a4efa38a5dbb3ae712ab77e5 in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b5d6917 ] GEODE-10182: Remove no longer needed null check. (#7504) > A null check due to detecting read conflict is no longer necessary > --- > > Key: GEODE-10182 > URL: https://issues.apache.org/jira/browse/GEODE-10182 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.12.2 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > The null check is introduced in fixing GEODE-6955, however, this check is no > long necessary after GEODE-8926 when transaction is applied to cache first > and handled it in attachFilterProfileInformation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10188) AvailablePortHelperIntegrationTest > initializeUniquePortRange_returnSamePortsForSameRange gets different ports on subsequent tries
[
https://issues.apache.org/jira/browse/GEODE-10188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514257#comment-17514257
]
Dale Emery commented on GEODE-10188:
A possible fix: Before the end of each test (perhaps in a finally block), tell
each {{Keeper}} to release its port. Like this:
{noformat}
results.forEach(Keeper::release);
{noformat}
I don’t know how soon a port becomes available after releasing. But I’m
guessing that if the {{Keeper}} isn’t explicitly released, the kept socket is
closed only after the {{Keeper}} is GCed.
> AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange gets different ports on
> subsequent tries
> ---
>
> Key: GEODE-10188
> URL: https://issues.apache.org/jira/browse/GEODE-10188
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.9
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Failed here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14294054]
>
> {noformat}
> > Task :geode-core:integrationTest
> org.apache.geode.internal.AvailablePortHelperIntegrationTest >
> initializeUniquePortRange_returnSamePortsForSameRange(useMembershipPortRange=true)
> FAILED
> org.junit.ComparisonFailure: expected:<[460[10, 46011, 4601]2]> but
> was:<[460[00, 46001, 4600]2]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.initializeUniquePortRange_returnSamePortsForSameRange(AvailablePortHelperIntegrationTest.java:322)
> 4023 tests completed, 1 failed, 82 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-results/integrationTest/1648509410/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.9-build.0668/test-artifacts/1648509410/integrationtestfiles-openjdk11-1.13.9-build.0668.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10191:
--
Labels: needsTriage (was: )
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
Donal Evans created GEODE-10191:
---
Summary: BLPOP command does not trigger when the target List is
created via a RENAME
Key: GEODE-10191
URL: https://issues.apache.org/jira/browse/GEODE-10191
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
BLPOP uses fired events from the LPUSH and RPUSH commands to trigger returning,
but it is also possible that a key will be created via RENAME, which does not
currently fire any events. The test below passes with open source Redis but
fails/hangs with geode-for-redis:
{code:java}
@Test
public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
String initialName = "{tag}initial";
String changedName = "{tag}changed";
jedis.lpush(initialName, "value1", "value2");
Future> future = executor.submit(() -> jedis.blpop(0,
changedName));
awaitEventDistributorSize(1);
jedis.rename(initialName, changedName);
assertThat(future.get()).containsExactly(changedName, "value2");
assertThat(jedis.lpop(changedName)).isEqualTo("value1");
} {code}
The RENAME command should be modified so that it fires events for the key being
created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10191) BLPOP command does not trigger when the target List is created via a RENAME
[
https://issues.apache.org/jira/browse/GEODE-10191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10191:
Labels: blocks-1.15.0 (was: needsTriage)
> BLPOP command does not trigger when the target List is created via a RENAME
> ---
>
> Key: GEODE-10191
> URL: https://issues.apache.org/jira/browse/GEODE-10191
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> BLPOP uses fired events from the LPUSH and RPUSH commands to trigger
> returning, but it is also possible that a key will be created via RENAME,
> which does not currently fire any events. The test below passes with open
> source Redis but fails/hangs with geode-for-redis:
> {code:java}
> @Test
> public void testBLPopWhenValueGetsCreated_withRename() throws Exception {
> String initialName = "{tag}initial";
> String changedName = "{tag}changed";
> jedis.lpush(initialName, "value1", "value2");
> Future> future = executor.submit(() -> jedis.blpop(0,
> changedName));
> awaitEventDistributorSize(1);
> jedis.rename(initialName, changedName);
> assertThat(future.get()).containsExactly(changedName, "value2");
> assertThat(jedis.lpop(changedName)).isEqualTo("value1");
> } {code}
> The RENAME command should be modified so that it fires events for the key
> being created.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10127) Incorrect locator hostname used in remote locator connections
[
https://issues.apache.org/jira/browse/GEODE-10127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514270#comment-17514270
]
ASF subversion and git services commented on GEODE-10127:
-
Commit 86b5f7b2ce4e85f8a82c0e0e0935fe2bad1b693a in geode's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=86b5f7b ]
GEODE-10127: Adds test to preserve correct marshalling behavior. (#7461)
* Assert that LocatorHelper.addServerLocator preserves the toString format.
* Assert that DistributionLocatorId.toString preserves the expected values
This includes the bind-address or hostname-for-client values if set.
> Incorrect locator hostname used in remote locator connections
> -
>
> Key: GEODE-10127
> URL: https://issues.apache.org/jira/browse/GEODE-10127
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> When locators in distributed system (DS) B as for locators in DS A they are
> sent the local host name and IP address of the locators and not that of the
> {{hostname-for-clients}} or {{bind-address}} properties.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10192) CI hang: testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
[
https://issues.apache.org/jira/browse/GEODE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514283#comment-17514283
]
Geode Integration commented on GEODE-10192:
---
Seen in [integration-test-openjdk8
#246|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/246]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/integrationTest/1648477166/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648477166/integrationtestfiles-openjdk8-1.15.0-build.1035.tgz].
> CI hang:
> testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> ---
>
> Key: GEODE-10192
> URL: https://issues.apache.org/jira/browse/GEODE-10192
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Hung here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291020]
> The only test in the "started" state is:
>
> {noformat}
> |2.3.1| bburcham-a01 in
> ~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
> ○ → progress -s started
> org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> Iteration: 1
> Start: 2022-03-28 13:41:07.109 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status: started
> {noformat}
> That JUnit test takes about 20s to run on a Macbook Pro.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10192) CI hang: testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
Bill Burcham created GEODE-10192:
Summary: CI hang:
testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
Key: GEODE-10192
URL: https://issues.apache.org/jira/browse/GEODE-10192
Project: Geode
Issue Type: Bug
Components: persistence
Affects Versions: 1.15.0
Reporter: Bill Burcham
Hung here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291020]
The only test in the "started" state is:
{noformat}
|2.3.1| bburcham-a01 in
~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
○ → progress -s started
org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
Iteration: 1
Start: 2022-03-28 13:41:07.109 +
End: 0001-01-01 00:00:00.000 +
Duration: 0s
Status: started
{noformat}
That JUnit test takes about 20s to run on a Macbook Pro.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10192) CI hang: testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
[
https://issues.apache.org/jira/browse/GEODE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10192:
--
Labels: needsTriage (was: )
> CI hang:
> testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> ---
>
> Key: GEODE-10192
> URL: https://issues.apache.org/jira/browse/GEODE-10192
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Hung here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291020]
> The only test in the "started" state is:
>
> {noformat}
> |2.3.1| bburcham-a01 in
> ~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
> ○ → progress -s started
> org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> Iteration: 1
> Start: 2022-03-28 13:41:07.109 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status: started
> {noformat}
> That JUnit test takes about 20s to run on a Macbook Pro.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10192) CI hang: testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
[
https://issues.apache.org/jira/browse/GEODE-10192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-10192:
-
Description:
Hung here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/246#C]
{noformat}
> Task :geode-for-redis:integrationTest
timeout exceeded
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/integrationTest/1648477166/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648477166/integrationtestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
The only test in the "started" state is:
{noformat}
|2.3.1| bburcham-a01 in
~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
○ → progress -s started
org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
Iteration: 1
Start: 2022-03-28 13:41:07.109 +
End: 0001-01-01 00:00:00.000 +
Duration: 0s
Status: started
{noformat}
That JUnit test takes about 20s to run on a Macbook Pro.
was:
Hung here: [https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14291020]
The only test in the "started" state is:
{noformat}
|2.3.1| bburcham-a01 in
~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
○ → progress -s started
org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
Iteration: 1
Start: 2022-03-28 13:41:07.109 +
End: 0001-01-01 00:00:00.000 +
Duration: 0s
Status: started
{noformat}
That JUnit test takes about 20s to run on a Macbook Pro.
> CI hang:
> testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> ---
>
> Key: GEODE-10192
> URL: https://issues.apache.org/jira/browse/GEODE-10192
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Priority: Major
> Labels: needsTriage
>
> Hung here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/246#C]
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> timeout exceeded
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-results/integrationTest/1648477166/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1035/test-artifacts/1648477166/integrationtestfiles-openjdk8-1.15.0-build.1035.tgz{noformat}
> The only test in the "started" state is:
>
> {noformat}
> |2.3.1| bburcham-a01 in
> ~/Downloads/integrationtestfiles-openjdk8-1.15.0-build.1035
> ○ → progress -s started
> org.apache.geode.internal.cache.DiskRandomOperationsAndRecoveryJUnitTest.testRollingEnabledRecoverValuesTruePersistWithOverFlowWithEarlyTerminationOfRoller
> Iteration: 1
> Start: 2022-03-28 13:41:07.109 +
> End: 0001-01-01 00:00:00.000 +
> Duration: 0s
> Status: started
> {noformat}
> That JUnit test takes about 20s to run on a Macbook Pro.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9879) Extract part of SystemPropertyHelper to geode-common for wider use
[ https://issues.apache.org/jira/browse/GEODE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514300#comment-17514300 ] ASF subversion and git services commented on GEODE-9879: Commit a8d932b286f94ec15464d179d860df048375f09b in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a8d932b ] GEODE-9879: Extract SystemProperty to geode-common (#7177) Extract part of SystemPropertyHelper to geode-common for use in modules that are upstream from geode-core. Define new DEFAULT_PREFIX that maps to GEODE_PREFIX and use that everywhere that GEODE_PREFIX was previously used. * Inline prefix constants in SystemPropertyHelper * Use static imports for system property prefixes. * Split up large tests in SystemPropertyHelperTest. * Fix JAXBService (cherry picked from commit ebf8479fffb5775b1f45801aa9382c2dad7106e0) > Extract part of SystemPropertyHelper to geode-common for wider use > -- > > Key: GEODE-9879 > URL: https://issues.apache.org/jira/browse/GEODE-9879 > Project: Geode > Issue Type: Wish > Components: core >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > I need to use the dual property prefix part of SystemPropertyHelper to > geode-common so that it can be used from non-core geode modules such as > geode-serialization. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9817) Allow analyze serializables tests to provide custom source set paths to ClassAnalysisRule
[ https://issues.apache.org/jira/browse/GEODE-9817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514297#comment-17514297 ] ASF subversion and git services commented on GEODE-9817: Commit 31375b759fcfa91d7df9749f3ffc556fa57f9d65 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=31375b7 ] GEODE-9817: Enable customized source set paths for ClassAnalysisRule (#7121) Adds support for customizing source set paths of ClassAnalysisRule. PROBLEM Modules external to Geode must be structured the same as Geode source code in order to use ClassAnalysisRule and the Analyze*Serializables tests. This is necessary to better facilitate pluggability of modules that need to provide sanctioned serializable lists. SOLUTION Add source set path customization to ClassAnalysisRule, introduce a new layer of Analyze*Serializables test base classes that can be directly extended in order to customize source set paths in ClassAnalysisRule. Also includes improvements to some iterating of classes during analysis. (cherry picked from commit 5d1e91932dff296632916a6ceccfb36039357acd) > Allow analyze serializables tests to provide custom source set paths to > ClassAnalysisRule > - > > Key: GEODE-9817 > URL: https://issues.apache.org/jira/browse/GEODE-9817 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.14.4, 1.15.0 > > > In order to make SanctionedSerializablesService and the related tests to be > more pluggable by external modules, I need to make changes to allow analyze > serializables tests to provide custom source set paths to ClassAnalysisRule. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514298#comment-17514298 ] ASF subversion and git services commented on GEODE-9758: Commit 6d0a4f10a5d75811d064726f57e19c15c47ad0b5 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6d0a4f1 ] GEODE-9758: Move SanctionedSerializables to filter package (#7165) Move SanctionedSerializables to new package org.apache.geode.internal.serialization.filter. (cherry picked from commit db64b4948e790d61e82f95ae6163a62adc4c67fb) > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514299#comment-17514299 ] ASF subversion and git services commented on GEODE-9758: Commit cc227bc894324d3e65cf06f085c645f063df8635 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cc227bc ] GEODE-9758: Move ClassUtils to geode-common (#7166) (cherry picked from commit b6fca291378a1bc334b0f9927c899a1892442939) > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9980) Startup of Locator or Server should fail fast if geode.enableGlobalSerialFilter is enabled but fails configuration
[
https://issues.apache.org/jira/browse/GEODE-9980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514302#comment-17514302
]
ASF subversion and git services commented on GEODE-9980:
Commit 9fc67eda1e6b64ab30548e97648efbb8440ab883 in geode's branch
refs/heads/support/1.14 from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9fc67ed ]
GEODE-9980: Improve error handling of serial filters (#7299)
Improves the error handling of serial filter configuration and
filtering. The API throws a runtime exception wrapping any thrown
exceptions.
When geode.enableGlobalSerialFilter is FALSE:
* Startup succeeds without throwing any exceptions even if an older
version of Java throws "java.lang.ClassNotFoundException
sun.misc.ObjectInputFilter".
When geode.enableGlobalSerialFilter is TRUE:
* Startup fails by throwing an exception when configuration of serial
filter fails for any reason.
Renames ObjectInputFilter to avoid confusion with the Java interface of
the same name.
Fixes a bug found in ReflectiveFacadeGlobalSerialFilterTest which
resulted in configuring a non-mocked process-wide serial filter that
polluted the JVM for all later tests.
Fixes other minor details in LocatorLauncher, InternalDataSerializer
and various related tests.
(cherry picked from commit ce57e9fd2b8b644cadc469209e12e4fbd281e0d9)
> Startup of Locator or Server should fail fast if
> geode.enableGlobalSerialFilter is enabled but fails configuration
> --
>
> Key: GEODE-9980
> URL: https://issues.apache.org/jira/browse/GEODE-9980
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available
>
> The following error conditions need better handling which includes handling
> of all errors consistently and cause the startup of a Locator or Server to
> fail if it's unable to honor the setting of
> {{-Dgeode.enableGlobalSerialFilter=true}} for any reason. Currently, if
> {{-Dgeode.enableGlobalSerialFilter=true}} is specified but Geode is unable to
> create a global serial filter, then it will will log a warning and continue
> running. A user may easily miss that log statement and believe that the JVM
> is running with a properly configured serialization filter.
> 1) The user is trying to secure the JVM very thoroughly and accidentally
> specifies both {{-Djdk.serialFilter}} and
> {{-Dgeode.enableGlobalSerialFilter}}.
> 2) The user runs some non-Geode code in the same JVM that invokes
> {{ObjectInputFilter.Config.setFilter(...)}} directly.
> 3) The user is using a version of Java 8 prior to 8u121 (the release that
> first added {{sun.misc.ObjectInputFilter}}) and specifies
> {{-Dgeode.enableGlobalSerialFilter=true}}. Also, the same behavior occurs if
> they do NOT specify enabling that property.
> 4) {{LocatorLauncher}} or {{ServerLauncher}} is started in a JVM that has
> already created at least one {{ObjectInputStream}} which will cause
> {{ObjectInputFilter.Config.setFilter(...)}} to fail.
> 5) {{LocatorLauncher}} or {{ServerLauncher}} is started in a Java 8 JVM that
> is not based on OpenJDK (ie {{sun.misc.ObjectInputFilter}} does not exist).
> 6) {{LocatorLauncher}} or {{ServerLauncher}} is started in an unforeseen
> environment that causes invocation of
> {{ObjectInputFilter.Config.setFilter(...)}} via Java Reflection to throw
> {{IllegalAccessException}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9758) Provide an easy to configure a process-wide serialization filter for use on Java 8
[ https://issues.apache.org/jira/browse/GEODE-9758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514301#comment-17514301 ] ASF subversion and git services commented on GEODE-9758: Commit 92e0e89c982ef4ed53e0a7be0194aea45adb8726 in geode's branch refs/heads/support/1.14 from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=92e0e89 ] GEODE-9758: Add internal serial filter API (#7217) GEODE-9758: Add internal serial filter API #7217 Expand ObjectInputStreamFilterWrapper to be an internal API which supports all of Geode's uses of Java's ObjectInputFilter. Introduce a new system property, geode.enableGlobalSerialFilter, to enable a process-wide filter with all serializable Geode classes on the classpath and the value of serializable-object-filter accept-listed. To enable the process-wide filter with GFSH start commands, add: * --J=-Dgeode.enableGlobalSerialFilter=true Functional Capabilities The internal API lives in geode-serialization and works on OpenJDK based JREs providing a facade for Java's ObjectInputFilter in Java 8 and Java 9 or greater using reflection. The API provides the following capabilities: * creating an ObjectInputFilter * setting an ObjectInputFilter on an ObjectInputStream * getting an ObjectInputFilter from a ObjectInputStream * setting a process-wide ObjectInputFilter * getting a process-wide ObjectInputFilter Design Notes The API defines the following primary interface types: * factory interfaces for creating instances of types within the API * filter interfaces to split out single ops from Java's ObjectInputFilter * configuration interfaces for handling system properties, logging, and config validation The concrete classes in the API receive parameters injected via a constructor for any collaborators that are not specified by the interfaces. This is intentional even when the instance is only used once before de-referencing it. All collaborators that are defined in the interface are passed in as parameters to the implementing method; all others are passed in via the constructor and stored as fields. (cherry picked from commit 7978abf34707d11da45cff0b7cb7445f18d21438) > Provide an easy to configure a process-wide serialization filter for use on > Java 8 > -- > > Key: GEODE-9758 > URL: https://issues.apache.org/jira/browse/GEODE-9758 > Project: Geode > Issue Type: Improvement > Components: configuration, serialization >Affects Versions: 1.12.7, 1.13.0, 1.14.0 >Reporter: Jianxia Chen >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, docs, pull-request-available > > Provide an easy way to configure a process-wide serialization filter for use > on Java 8. When enabled, validate-serializable-objects should be enabled and > the process-wide serialization filter should be configured to accept only JDK > classes and Geode classes in addition to anything the user might specify with > serializable-object-filter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10121:
---
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0)
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10193) QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10193:
---
Labels: Java17 (was: )
> QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17
> -
>
> Key: GEODE-10193
> URL: https://issues.apache.org/jira/browse/GEODE-10193
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> The {{QueryPdxDataDUnitTest}} class setup method uses the
> {{net.openhft.compiler}} library's {{CachedCompiler}} to dynamically build
> several java classes in child VMs. The {{CacheCompiler}} class's static
> initializer attempts to access the {{override}} field of the system's
> {{Unsafe}} instance. On JDK 17, the attempt throws
> {{{}NoSuchFieldException{}}}.
> Stack trace:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.QueryPdxDataDUnitTest$$Lambda$489/0x0008010cd4b8.run
> in VM 3 running on Host
> heavy-lifter-03dd4ef3-5b5a-50e9-a355-9c3a43ac89c7.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:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.management.QueryPdxDataDUnitTest.beforeClass(QueryPdxDataDUnitTest.java:81)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> 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 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI
[jira] [Created] (GEODE-10193) QueryPdxDataDUnitTest accesses Unsafe field that does not exist on JDK 17
Dale Emery created GEODE-10193:
--
Summary: QueryPdxDataDUnitTest accesses Unsafe field that does not
exist on JDK 17
Key: GEODE-10193
URL: https://issues.apache.org/jira/browse/GEODE-10193
Project: Geode
Issue Type: Improvement
Components: tests
Affects Versions: 1.15.0
Reporter: Dale Emery
The {{QueryPdxDataDUnitTest}} class setup method uses the
{{net.openhft.compiler}} library's {{CachedCompiler}} to dynamically build
several java classes in child VMs. The {{CacheCompiler}} class's static
initializer attempts to access the {{override}} field of the system's
{{Unsafe}} instance. On JDK 17, the attempt throws {{{}NoSuchFieldException{}}}.
Stack trace:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.management.QueryPdxDataDUnitTest$$Lambda$489/0x0008010cd4b8.run
in VM 3 running on Host
heavy-lifter-03dd4ef3-5b5a-50e9-a355-9c3a43ac89c7.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:448)
at
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
at
org.apache.geode.management.QueryPdxDataDUnitTest.beforeClass(QueryPdxDataDUnitTest.java:81)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at
org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:139)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
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 jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:568)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(Reflection
[jira] [Commented] (GEODE-9617) CI Failure: PartitionedRegionSingleHopDUnitTest fails with ConditionTimeoutException waiting for server to bucket map size
[
https://issues.apache.org/jira/browse/GEODE-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514334#comment-17514334
]
Geode Integration commented on GEODE-9617:
--
Seen in [distributed-test-openjdk8
#253|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/253]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1040/test-results/distributedTest/1648582454/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1040/test-artifacts/1648582454/distributedtestfiles-openjdk8-1.15.0-build.1040.tgz].
> CI Failure: PartitionedRegionSingleHopDUnitTest fails with
> ConditionTimeoutException waiting for server to bucket map size
> --
>
> Key: GEODE-9617
> URL: https://issues.apache.org/jira/browse/GEODE-9617
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testClientMetadataForPersistentPrs FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest that uses
> org.apache.geode.cache.client.internal.ClientMetadataService,
> org.apache.geode.cache.client.internal.ClientMetadataServiceorg.apache.geode.cache.Region
>
> Expecting actual not to be null within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> 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:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs(PartitionedRegionSingleHopDUnitTest.java:971)
> Caused by:
> java.lang.AssertionError:
> Expecting actual not to be null
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:976)
> {noformat}
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataServiceCallAccuracy_FromGetOp FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest that uses
> org.apache.geode.cache.client.internal.ClientMetadataService
> Expecting value to be false but was true expected:<[fals]e> but
> was:<[tru]e> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> 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:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataServiceCallAccuracy_FromGetOp(PartitionedRegionSingleHopDUnitTest.java:394)
> Caused by:
> org.junit.ComparisonFailure:
> Expecting value to be false but was true expected:<[fals]e> but
> was:<[tru]e>
> at sun.reflect.GeneratedConstructorAccessor29.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testMetadataServiceCallAccuracy_FromGetOp$6(PartitionedRegionSingleHopDUnitTest.java:395)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10194) Redis LSET against nonexistent key produces incorrect error
Ray Ingles created GEODE-10194: -- Summary: Redis LSET against nonexistent key produces incorrect error Key: GEODE-10194 URL: https://issues.apache.org/jira/browse/GEODE-10194 Project: Geode Issue Type: Bug Components: redis Reporter: Ray Ingles When the command "lset nosuchkey 10 foo" is run against Geode for Redis, it produces the error: ERR index out of range but it should produce the error: ERR no such key -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10194) Redis LSET against nonexistent key produces incorrect error
[ https://issues.apache.org/jira/browse/GEODE-10194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10194: -- Labels: needsTriage (was: ) > Redis LSET against nonexistent key produces incorrect error > --- > > Key: GEODE-10194 > URL: https://issues.apache.org/jira/browse/GEODE-10194 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Ray Ingles >Priority: Major > Labels: needsTriage > > When the command "lset nosuchkey 10 foo" is run against Geode for Redis, it > produces the error: > ERR index out of range > but it should produce the error: > ERR no such key -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10058) Remove Defunct NetCore and C-Bindings from geode-native repo and CI
[ https://issues.apache.org/jira/browse/GEODE-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514344#comment-17514344 ] ASF GitHub Bot commented on GEODE-10058: lgtm-com[bot] commented on pull request #950: URL: https://github.com/apache/geode-native/pull/950#issuecomment-1082424840 This pull request **fixes 4 alerts** when merging a2886eaf9d513452a587af64f2b49fd00fea176c into 4b2f2462a3bae783cb3e03e3186a58707945fa10 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-43933a700f6e8231e9ee0079cd2a7613fc7597d3) **fixed alerts:** * 4 for Dereferenced variable may be null -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Remove Defunct NetCore and C-Bindings from geode-native repo and CI > --- > > Key: GEODE-10058 > URL: https://issues.apache.org/jira/browse/GEODE-10058 > Project: Geode > Issue Type: Task >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > This project is being replaced by a pure C# client for .NET Core. > Also, move the SessionState code to a new branch since it's not throw away > code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10195) MicrometerBinderTest > processorMetricsBinderExists FAILED
[
https://issues.apache.org/jira/browse/GEODE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-10195:
--
Labels: needsTriage (was: )
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> --
>
> Key: GEODE-10195
> URL: https://issues.apache.org/jira/browse/GEODE-10195
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> windows-acceptance-test-openjdk11 failed with the following error.
>
> {noformat}
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-ceacbfa8-6147-51ca-affd-b497cd16e2ef(4420:loner):54545:7074b0d7:
> Function named CheckIfMeterExistsFunction is not registered to FunctionService
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377)
> at
> org.apache.geode.metrics.MicrometerBinderTest.processorMetricsBinderExists(MicrometerBinderTest.java:152)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10195) MicrometerBinderTest > processorMetricsBinderExists FAILED
Mark Hanson created GEODE-10195:
---
Summary: MicrometerBinderTest > processorMetricsBinderExists FAILED
Key: GEODE-10195
URL: https://issues.apache.org/jira/browse/GEODE-10195
Project: Geode
Issue Type: Bug
Components: core
Reporter: Mark Hanson
windows-acceptance-test-openjdk11 failed with the following error.
{noformat}
MicrometerBinderTest > processorMetricsBinderExists FAILED
org.apache.geode.cache.client.ServerOperationException: remote server on
heavy-lifter-ceacbfa8-6147-51ca-affd-b497cd16e2ef(4420:loner):54545:7074b0d7:
Function named CheckIfMeterExistsFunction is not registered to FunctionService
at
org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394)
at
org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
at
org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
at
org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100)
at
org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217)
at
org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104)
at
org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368)
at
org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377)
at
org.apache.geode.metrics.MicrometerBinderTest.processorMetricsBinderExists(MicrometerBinderTest.java:152)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10195) MicrometerBinderTest > processorMetricsBinderExists FAILED
[
https://issues.apache.org/jira/browse/GEODE-10195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514358#comment-17514358
]
Geode Integration commented on GEODE-10195:
---
Seen in [windows-acceptance-test-openjdk11
#240|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-acceptance-test-openjdk11/builds/240]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1042/test-results/acceptanceTest/1648593722/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1042/test-artifacts/1648593722/windows-acceptancetestfiles-openjdk11-1.15.0-build.1042.tgz].
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> --
>
> Key: GEODE-10195
> URL: https://issues.apache.org/jira/browse/GEODE-10195
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> windows-acceptance-test-openjdk11 failed with the following error.
>
> {noformat}
> MicrometerBinderTest > processorMetricsBinderExists FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-ceacbfa8-6147-51ca-affd-b497cd16e2ef(4420:loner):54545:7074b0d7:
> Function named CheckIfMeterExistsFunction is not registered to FunctionService
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp$ExecuteFunctionOpImpl.processResponse(ExecuteFunctionOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:234)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:209)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:394)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:760)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:151)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:820)
> at
> org.apache.geode.cache.client.internal.ExecuteFunctionOp.execute(ExecuteFunctionOp.java:100)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeOnServer(ServerFunctionExecutor.java:217)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.executeFunction(ServerFunctionExecutor.java:104)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:368)
> at
> org.apache.geode.internal.cache.execute.ServerFunctionExecutor.execute(ServerFunctionExecutor.java:377)
> at
> org.apache.geode.metrics.MicrometerBinderTest.processorMetricsBinderExists(MicrometerBinderTest.java:152)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
Dale Emery created GEODE-10196:
--
Summary: HashesAndCrashesDUnitTest fails to ignore expected
exceptions on JDK 17
Key: GEODE-10196
URL: https://issues.apache.org/jira/browse/GEODE-10196
Project: Geode
Issue Type: Improvement
Components: tests
Affects Versions: 1.15.0
Reporter: Dale Emery
The \{{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
of the test in the class) expects exceptions with the message "Connection reset
by peer", logs them, and retries the operation.
The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
exception message is "Connection reset". This is not the expected message, and
so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing the
test to fail.
Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}}, but
on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test, which
inspects only the exception message, not the type.
On JDK 17, the stack trace of the exception is:
```
io.lettuce.core.RedisException: java.net.SocketException: Connection reset
at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
at
io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
at
io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
at
java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.net.SocketException: Connection reset
at
java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
... 1 more
```
On JDK 11, the stack trace of the exception is:
```
io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
at
io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
at
io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
at com.sun.proxy.$Proxy52.set(Unknown Source)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$8(HashesAndCrashesDUnitTest.java:158)
at
java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor
[jira] [Updated] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10196:
---
Labels: Java17 (was: )
> HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
> ---
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> The \{{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by
> all of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> ```
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> ```
>
> On JDK 11, the stack trace of the exception is:
> ```
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.comman
[jira] [Updated] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10196:
---
Description:
The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
of the test in the class) expects exceptions with the message "Connection reset
by peer", logs them, and retries the operation.
The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
exception message is "Connection reset". This is not the expected message, and
so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing the
test to fail.
Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}}, but
on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test, which
inspects only the exception message, not the type.
On JDK 17, the stack trace of the exception is:
{noformat}
io.lettuce.core.RedisException: java.net.SocketException: Connection reset
at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
at
io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
at
io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
at
java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.net.SocketException: Connection reset
at
java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
at
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
at
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
at
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
at
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
... 1 more
{noformat}
On JDK 11, the stack trace of the exception is:
{noformat}
io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
at
io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
at
io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
at com.sun.proxy.$Proxy52.set(Unknown Source)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
at
org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$8(HashesAndCrashesDUnitTest.java:158)
at
java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1736)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.io.IOException:
[jira] [Updated] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10197: -- Labels: needsTriage (was: ) > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
Darrel Schneider created GEODE-10197: Summary: OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists Key: GEODE-10197 URL: https://issues.apache.org/jira/browse/GEODE-10197 Project: Geode Issue Type: Bug Components: tests Reporter: Darrel Schneider This test is explicitly adding CMSInitiatingOccupancyFraction but cms has been removed in later java releases. OutOfMemoryDUnitTest > initializationError FAILED org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures (2 failures) org.opentest4j.AssertionFailedError: [The Cache Server process terminated unexpectedly with exit status 1. Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10197: - Labels: Java17 (was: needsTriage) > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Priority: Major > Labels: Java17 > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10183) Create tests for Transaction with loaders which can throw CommitConflictException
[ https://issues.apache.org/jira/browse/GEODE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10183: --- Labels: pull-request-available (was: ) > Create tests for Transaction with loaders which can throw > CommitConflictException > - > > Key: GEODE-10183 > URL: https://issues.apache.org/jira/browse/GEODE-10183 > Project: Geode > Issue Type: Test >Reporter: Geet Rawat >Assignee: Geet Rawat >Priority: Major > Labels: pull-request-available > > We need test coverage for conflicting transactions which involves > cacheLoaders. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-10190. Fix Version/s: 1.15.0 Resolution: Fixed > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10190) Improve runtime of some Redis integration tests
[ https://issues.apache.org/jira/browse/GEODE-10190?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17514415#comment-17514415 ] ASF subversion and git services commented on GEODE-10190: - Commit 7c010278dfd8afbbd202d5f541932a8eabbbae26 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7c01027 ] GEODE-10190: Improve runntime of MSetIntegrationTest and RenameIntegratinoTest (#7511) - Reduce the iterations and/or elements used by these tests reducing the runtimes significantly (down to seconds instead of minutes). > Improve runtime of some Redis integration tests > --- > > Key: GEODE-10190 > URL: https://issues.apache.org/jira/browse/GEODE-10190 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > From Darrel: > _I’m doing some refactoring of the ResourceManager and my pr’s integration > tests are timing out after running for 45 minutes. Normally integration tests > take 18 minutes. When looking at whats tests took a long time I see that > AbstractRenameIntegrationTest#shouldRenameAtomically took 8 minutes each time > it was run. On my laptop I see it run in 2.75 minutes. Another test method I > see take over 7 minutes is testMSet_concurrentInstances_mustBeAtomic. These > two methods are run twice so that adds up to 30 minutes in just two test > methods so I think that is the cause of the timeout. Both of these do > concurrency. Any ideas about this? Do you think my refactoring broke > something or did I just get a bad run of these tests?_ > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10189) Errors encountered during Apache Geode upgrade
[
https://issues.apache.org/jira/browse/GEODE-10189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swetha Sudheesh updated GEODE-10189:
Description:
We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1* version
to avoid any vulnerabilities. We also added all the dependencies mentioned in
the Maven with the latest versions. Our application uses {*}JDK 11{*}. We faced
few issues such as the one described below:
Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
at
org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
at
org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
at
org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
wrong class: UUID*
at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
... 17 more
Please let us know why we are encountering this error and how can it be
resolved? Also let us know the right dependencies that need to be added for
Apache Geode 1.14.1 upgrade.
was:
We are trying to upgrade Apache Geode from *1.8.0* version to *1.14.1* version
to avoid any vulnerabilities. We also added all the dependencies mentioned in
the Maven with the latest versions. We faced few issues such as the one
described below:
Exception in thread "Locator" *java.lang.ExceptionInInitializerError*
at
org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)
at
org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)
at
org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:152)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:219)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
at
org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
at
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
at
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
Caused by: *java.lang.IllegalStateException: JGAddress.create() returned the
wrong class: UUID*
at org.jgroups.conf.ClassConfigurator.add(ClassConfigurator.java:101)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.(JGroupsMessenger.java:167)
... 17 more
Please let us know why we are encountering this error and how can it be
resolved? Also let us know the right dependencies that need to be added for
Apache Geode 1.14.1 upgrade.
> Errors encountered during Apache Geode upg
