[jira] [Commented] (GEODE-10030) Remove obsolete cross-reference in geode-native user docs
[ https://issues.apache.org/jira/browse/GEODE-10030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507928#comment-17507928 ] ASF subversion and git services commented on GEODE-10030: - Commit 0b46698c7a0be115256d0e44d5614afa957ac071 in geode-native's branch refs/heads/support/1.15.old from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=0b46698 ] GEODE-10030: Remove obsolete cross-reference in geode-native user docs (#921) > Remove obsolete cross-reference in geode-native user docs > - > > Key: GEODE-10030 > URL: https://issues.apache.org/jira/browse/GEODE-10030 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.12.9, 1.13.8, 1.14.4, 1.15.0 > > > The System Properties page contains a cross-reference to the System > Statistics page, which no longer exists. Just remove the link from both the > .NET and C++ versions of the user guide. It's in the System Archiving > Properties table. > .NET: > https://geode.apache.org/docs/geode-native/dotnet/114/configuring/sysprops.html#attributes-gfcpp__table_durable_client_props > C++: > https://geode.apache.org/docs/geode-native/cpp/114/configuring/sysprops.html -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10089) release 1.15.0
[ https://issues.apache.org/jira/browse/GEODE-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507904#comment-17507904 ] ASF subversion and git services commented on GEODE-10089: - Commit 0ed742ced039ea5ba6de7a637976ce0152f2ac15 in geode-benchmarks's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=0ed742c ] GEODE-10089: set version number to 1.15 to correspond with develop > release 1.15.0 > -- > > Key: GEODE-10089 > URL: https://issues.apache.org/jira/browse/GEODE-10089 > Project: Geode > Issue Type: Task > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > > As per [Jan 25 dev list > discussion|https://lists.apache.org/thread/s9mpd207h40crcr76fpdfmohdchgdqog], > support/1.15 was cut with the intention of stabilizing and releasing a new > Geode minor. > Release status information is also updated in the Geode [Release > Schedule|https://cwiki.apache.org/confluence/display/GEODE/Release+Schedule]. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10131) Remove unused but set variable
Michael Oleske created GEODE-10131: -- Summary: Remove unused but set variable Key: GEODE-10131 URL: https://issues.apache.org/jira/browse/GEODE-10131 Project: Geode Issue Type: Task Components: native client Reporter: Michael Oleske When on AppleClang 13.1.6.13160021 on macOS 12.3, native client fails to compile due to warning as error -Wunused-but-set-variable Remove the offending lines to compile -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10054) CI Failure: EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary fails because primary moved
[
https://issues.apache.org/jira/browse/GEODE-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10054:
-
Fix Version/s: 1.15.0
> CI Failure: EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary
> fails because primary moved
> -
>
> Key: GEODE-10054
> URL: https://issues.apache.org/jira/browse/GEODE-10054
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Hale Bales
>Assignee: Hale Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> This test fails with the following stack trace because the primary moved when
> it wasn't supposed to.
> {code:java}
> EnsurePrimaryStaysPutDUnitTest > localFunctionRetriesIfNotOnPrimary FAILED
> org.opentest4j.AssertionFailedError: [CheckPrimaryBucketFunction
> determined that the primary has moved]
> Expecting value to be true but was false
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest.primaryRemainsWhileFunctionExecutes(EnsurePrimaryStaysPutDUnitTest.java:170)
> at
> org.apache.geode.redis.EnsurePrimaryStaysPutDUnitTest.localFunctionRetriesIfNotOnPrimary(EnsurePrimaryStaysPutDUnitTest.java:93)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9985) Mass-Test-Run: SlowDispatcherDUnitTest > registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
[
https://issues.apache.org/jira/browse/GEODE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9985:
Fix Version/s: 1.15.0
> Mass-Test-Run: SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> --
>
> Key: GEODE-9985
> URL: https://issues.apache.org/jira/browse/GEODE-9985
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> {code:java}
> SlowDispatcherDUnitTest >
> registeredInterest_durableClient_kill_primarySever_receives_marker FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest$$Lambda$299/1561169457.run
> in VM 3 running on Host
> heavy-lifter-f18312bf-ecf3-5384-8b36-e5d91bf8ebb9.c.apachegeode-ci.internal
> with 5 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.internal.cache.tier.sockets.SlowDispatcherDUnitTest.registeredInterest_durableClient_kill_primarySever_receives_marker(SlowDispatcherDUnitTest.java:135)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest
> expected: 49
> but was: 40 within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> 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.tier.sockets.SlowDispatcherDUnitTest.lambda$registeredInterest_durableClient_kill_primarySever_receives_marker$bb17a952$2(SlowDispatcherDUnitTest.java:137)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: 49
> but was: 40
> at
> sun.reflect.GeneratedConstructorAccessor21.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.SlowDispatcherDUnitTest.lambda$null$2(SlowDispatcherDUnitTest.java:137)
> 8357 tests completed, 1 failed, 414 skipped
> {code}
> Test report artifacts from {color:#172b4d}this{color} job are available at:
> http:{color:#172b4d}//files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642831372/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz{color}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9976) Edit CODEOWNERS mappings for kirklund
[ https://issues.apache.org/jira/browse/GEODE-9976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9976: Fix Version/s: 1.15.0 > Edit CODEOWNERS mappings for kirklund > - > > Key: GEODE-9976 > URL: https://issues.apache.org/jira/browse/GEODE-9976 > Project: Geode > Issue Type: Wish >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Edit CODEOWNERS mappings for kirklund -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9984) Mass-Test-Run: WanCopyRegionCommandDUnitTest > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED
[ https://issues.apache.org/jira/browse/GEODE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9984: Fix Version/s: 1.15.0 > Mass-Test-Run: WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED > - > > Key: GEODE-9984 > URL: https://issues.apache.org/jira/browse/GEODE-9984 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Alberto Gomez >Priority: Major > Labels: flaky-test, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(true, true) [0] FAILED > org.opentest4j.AssertionFailedError: > expected: 5 > but was: 50001 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(WanCopyRegionCommandDUnitTest.java:884) > 948 tests completed, 1 failed, 59 skipped > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642850654/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz*] > > > > May be an issue similar or related to > https://issues.apache.org/jira/browse/GEODE-9859. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10117) Add doc section mentioning the relationship between local-max-memory and lru eviction memory
[ https://issues.apache.org/jira/browse/GEODE-10117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10117: - Fix Version/s: 1.15.0 > Add doc section mentioning the relationship between local-max-memory and lru > eviction memory > > > Key: GEODE-10117 > URL: https://issues.apache.org/jira/browse/GEODE-10117 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Section to be added : > **Note:** For partition regions if the partition region attribute > `local-max-memory` is set then the eviction attribute `lru-memory-size > maximum` is overwritten with the value of `local-max-memory` > Both `local-max-memory` and `lru-memory-size maximum` are local > member attributes and not cluster-wide. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10108) Duplicate Ops During GII/Delta Updates
[ https://issues.apache.org/jira/browse/GEODE-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10108: - Fix Version/s: 1.15.0 > Duplicate Ops During GII/Delta Updates > --- > > Key: GEODE-10108 > URL: https://issues.apache.org/jira/browse/GEODE-10108 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > When Redis commands are ongoing and a server that was previously not hosting > a bucket becomes the host of the primary bucket for a key, there exists a > time window where that server is performing GII but also receiving delta > updates from the previous primary bucket. This can lead to the delta being > applied to a data structure that is already in the “correct” state, resulting > in the command being applied twice. This can result in duplicated appends, > increments/decrements, and in the case of LTRIP and RPOP especially, > IndexOutOfBoundsException on the member applying the delta, as the index to > which the delta refers has already been removed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9694) Remove deprecated elements from QueryCommandDUnitTestBase
[ https://issues.apache.org/jira/browse/GEODE-9694?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9694: Fix Version/s: 1.15.0 > Remove deprecated elements from QueryCommandDUnitTestBase > - > > Key: GEODE-9694 > URL: https://issues.apache.org/jira/browse/GEODE-9694 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10094) NPE could be encountered when accessing index manager if cache is closing
[ https://issues.apache.org/jira/browse/GEODE-10094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10094: - Fix Version/s: 1.15.0 > NPE could be encountered when accessing index manager if cache is closing > - > > Key: GEODE-10094 > URL: https://issues.apache.org/jira/browse/GEODE-10094 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The following NPE can be seen when creating index on a partitioned region. > java.lang.NullPointerException > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.populateEmptyIndexes(PartitionedRegion.java:8601) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8519) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:288) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at Remote Member > 'rs-GEM-3234-HG1109a1i32xlarge-hydra-client-17(gemfire2_host1_10121:10121):41001' > in java.lang.Thread.run(Thread.java:750) > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:86) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:859) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:483) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8418) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8335) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:248) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:206) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:277) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:200) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10110) When creating index in geode, InternalGemFireException should not be thrown to user if hitting CacheClosedException
[ https://issues.apache.org/jira/browse/GEODE-10110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10110: - Fix Version/s: 1.15.0 > When creating index in geode, InternalGemFireException should not be thrown > to user if hitting CacheClosedException > --- > > Key: GEODE-10110 > URL: https://issues.apache.org/jira/browse/GEODE-10110 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Here is the exception thrown to the user: > org.apache.geode.InternalGemFireException: unexpected exception on member > rs-FullRegression27464262a7i32xlarge-hydra-client-57(gemfire2_host1_13415:13415):41003 > at > org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:98) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage$PartitionResponse.waitForCacheException(PartitionMessage.java:852) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg$IndexCreationResponse.waitForResult(IndexCreationMsg.java:481) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8536) > at > org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274) > at > org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:197) > Caused by: Creation of index: statusIndex failed due to: > org.apache.geode.cache.CacheClosedException: The cache is closed. > at > org.apache.geode.internal.cache.PartitionedRegion.createIndexes(PartitionedRegion.java:8648) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.operateOnPartitionedRegion(IndexCreationMsg.java:125) > at > org.apache.geode.internal.cache.partitioned.IndexCreationMsg.process(IndexCreationMsg.java:286) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:446) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doPartitionRegionThread(ClusterOperationExecutors.java:426) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9981:
Fix Version/s: 1.15.0
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10075) Fix support for jacoco code coverage in Geode build
[ https://issues.apache.org/jira/browse/GEODE-10075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10075: - Fix Version/s: 1.15.0 > Fix support for jacoco code coverage in Geode build > --- > > Key: GEODE-10075 > URL: https://issues.apache.org/jira/browse/GEODE-10075 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > We haven't been maintaining this gradle build support, but it is useful to be > able to get code coverage from distributed test runs, eg. > ./gradlew geode-core:distributedTest -PcodeCoverage --tests XXX > geode-core:jacocoDistributedTestReport > If you pass -PcodeCoverage it's currently failing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9853) Optimize number of ParallelQueueRemovalMessage sent for dropped events in large clusters
[ https://issues.apache.org/jira/browse/GEODE-9853?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9853: Fix Version/s: 1.15.0 > Optimize number of ParallelQueueRemovalMessage sent for dropped events in > large clusters > > > Key: GEODE-9853 > URL: https://issues.apache.org/jira/browse/GEODE-9853 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > In multi site cluster (16 or more servers), in case we stop gw sender, and > continue to put new entries in region, it is observed large number of > ParallelQueueRemovalMessage sent. > It seems that this can be optimized, since most of sent messages are ignored > by most of other servers. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10083) Fix RedisProxy to correctly process MOVED responses
[ https://issues.apache.org/jira/browse/GEODE-10083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10083: - Fix Version/s: 1.15.0 > Fix RedisProxy to correctly process MOVED responses > --- > > Key: GEODE-10083 > URL: https://issues.apache.org/jira/browse/GEODE-10083 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The RedisProxy test helper rewrites various redis responses to allow for > address translation when using a docker-based redis cluster. Due to the way > the internal netty processing pipeline was constructed, a received MOVED > response could have disrupted subsequent requests flowing through the proxy. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9972) remove 'wait overnight' step from release process
[ https://issues.apache.org/jira/browse/GEODE-9972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9972: Fix Version/s: 1.15.0 > remove 'wait overnight' step from release process > - > > Key: GEODE-9972 > URL: https://issues.apache.org/jira/browse/GEODE-9972 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > now that maven central syncs within 1 hour and closer.cgi mirrors use the new > dlcdn which syncs within 15 minutes, we can eliminate the overnight step in > the release steps -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10046: - Fix Version/s: 1.15.0 > bump dependencies in 1.16 > - > > Key: GEODE-10046 > URL: https://issues.apache.org/jira/browse/GEODE-10046 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > until support/1.16 is cut, periodically check for and switch to latest > version of 3rd-party dependencies. this will extend the shelf-life of > eventual Geode 1.16 release and hopefully reduce bugs and cve exposure, or at > least give a smaller delta if there is later a cve found that we need to > patch for -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8140) Ability to set the scope of a replicated region using gfsh and describe must display scope
[ https://issues.apache.org/jira/browse/GEODE-8140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8140: Fix Version/s: 1.15.0 > Ability to set the scope of a replicated region using gfsh and describe must > display scope > -- > > Key: GEODE-8140 > URL: https://issues.apache.org/jira/browse/GEODE-8140 > Project: Geode > Issue Type: Task > Components: docs, gfsh >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > * Right now if we are create RR using gfsh and want to set scope, we have to > create region using gfsh, export config , modify the config and restart the > server. > * Fix to include a scope field in create region in gfsh while creating a RR > region > * describe region will also now display the scope. Previously the default > values are not displayed -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9978) Remove test-container from Geode
[ https://issues.apache.org/jira/browse/GEODE-9978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9978: Fix Version/s: 1.15.0 > Remove test-container from Geode > > > Key: GEODE-9978 > URL: https://issues.apache.org/jira/browse/GEODE-9978 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > We don't use it for testing anymore. Excise it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9710) Clean up PRColocationDUnitTestHelper
[ https://issues.apache.org/jira/browse/GEODE-9710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9710: Fix Version/s: 1.15.0 > Clean up PRColocationDUnitTestHelper > > > Key: GEODE-9710 > URL: https://issues.apache.org/jira/browse/GEODE-9710 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10034) Organize Geode For Redis Stats By Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10034: - Fix Version/s: 1.15.0 > Organize Geode For Redis Stats By Data Structure > > > Key: GEODE-10034 > URL: https://issues.apache.org/jira/browse/GEODE-10034 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The Geode for Redis Stats should be organized by Data Structure. For the > stats not associated with a data structure, the stats should continue to be > exposed under > "GeodeForRedisStats". > > +Acceptance Criteria+ > All stats, associated with a command specific to a data structure, should be > exposed under that data structure (e.g. Strings, Sets, SortedSets, Hashes, > Lists). > > All tests should pass. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10086) Remove unnecessary String builder in Size.java
[
https://issues.apache.org/jira/browse/GEODE-10086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10086:
-
Fix Version/s: 1.15.0
> Remove unnecessary String builder in Size.java
> --
>
> Key: GEODE-10086
> URL: https://issues.apache.org/jira/browse/GEODE-10086
> Project: Geode
> Issue Type: Bug
>Reporter: Nabarun Nag
>Assignee: Nabarun Nag
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Previously:
> {code:java}
> errMessage
> .append(String.format("The input region name for the %s request is
> null",
> "size"));
> writeErrorResponse(clientMessage, MessageType.SIZE_ERROR,
> errMessage.toString(), {code}
> There is no need for a String builder, a local string will do the job
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9809: Fix Version/s: 1.15.0 > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. > In our test, in cluster with 50 servers, we have leader persisted partitioned > region with more than 1000 buckets, and colocated 2 persisted regions. If we > consecutively create and destroy child regions, memory leak is observed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10019) add jira id to release-related commits
[ https://issues.apache.org/jira/browse/GEODE-10019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10019: - Fix Version/s: 1.15.0 > add jira id to release-related commits > -- > > Key: GEODE-10019 > URL: https://issues.apache.org/jira/browse/GEODE-10019 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > problem: commits generated during release process fail to adhere to Geode > commit-message standards: they do not include a Jira ticket. > > solution: add a required -j parameter to all release scripts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9708) Clean up FunctionCommandsDistributedTestBase
[ https://issues.apache.org/jira/browse/GEODE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9708: Fix Version/s: 1.15.0 > Clean up FunctionCommandsDistributedTestBase > - > > Key: GEODE-9708 > URL: https://issues.apache.org/jira/browse/GEODE-9708 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Nabarun Nag >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10021) Clean up RemoteTrasactionDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-10021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10021: - Fix Version/s: 1.15.0 > Clean up RemoteTrasactionDUnitTest > -- > > Key: GEODE-10021 > URL: https://issues.apache.org/jira/browse/GEODE-10021 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0, 1.16.0 >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > I have been working on GEODE-9929 and the failing DUnitTest has a lot of > errors. I want to clean up some of the errors where I can use find and > replace, as well as a couple of changes to make it easier for the next person > who works on GEODE-9929. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10010:
-
Fix Version/s: 1.15.0
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9859) Mass-Test-Run: WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false, false) [0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9859:
Fix Version/s: 1.15.0
> Mass-Test-Run:
> WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
>
>
> Key: GEODE-9859
> URL: https://issues.apache.org/jira/browse/GEODE-9859
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Looks like this might be failing from the original PR. I have linked to
> GEODE-9369 as the most likely origination.
>
> {noformat}
> WanCopyRegionCommandDUnitTest > testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
> java.lang.AssertionError:
> Expecting elements:
> ["Execution failed. Error:
> org.apache.geode.cache.EntryDestroyedException: 937"]
> to have exactly 1 times execution error
> at
> org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(WanCopyRegionCommandDUnitTest.java:450)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9706) OutOfMemoryDUnitTest can be improved
[
https://issues.apache.org/jira/browse/GEODE-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9706:
Fix Version/s: 1.15.0
> OutOfMemoryDUnitTest can be improved
>
>
> Key: GEODE-9706
> URL: https://issues.apache.org/jira/browse/GEODE-9706
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Darrel Schneider
>Assignee: Donal Evans
>Priority: Minor
> Fix For: 1.15.0, 1.16.0
>
>
> Kirk Lund made the following suggestions for improving OutOfMemoryDUnitTest:
> You might want to consider using ExecutorServiceRule or
> DistributedExecutorServiceRule with a CompletableFuture instead of directly
> using a thread:
> {code:java}
> @Rule
> public ExecutorServiceRule executorServiceRule = new ExecutorServiceRule();
> CompletableFuture memoryPressure = executorServiceRule.runAsync(()
> -> {
> try {
> while (true) {
> Thread.sleep(1000);
> }
> } catch (InterruptedException e) {
> // done
> }
> });
> // do something
> memoryPressure.cancel(true);
> {code}
> The cancel(true) will interrupt the thread. If the test throws before that,
> ExecutorServiceRule will clean up any threads during tear down by invoking
> shutdownNow which will also interrupt any running threads. If the thread
> resists interrupt and hangs, the rule should print a stack trace for it as a
> test failure which would then make it easy to debug.
> ExecutorServiceRule will work well within the controller JVM. If you need a
> version of the rule that works within any JVM in a dunit test, then use
> DistributedExecutorServiceRule.
> Also when the test does a "join()" add a timeout like so:
> {code:java}
> join(GeodeAwaitility.getTimeout().getSeconds(), TimeUnit.SECONDS);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9950) Implement LRANGE
[ https://issues.apache.org/jira/browse/GEODE-9950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9950: Fix Version/s: 1.15.0 > Implement LRANGE > > > Key: GEODE-9950 > URL: https://issues.apache.org/jira/browse/GEODE-9950 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Implement the LRANGE command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9947) Implement LINDEX
[ https://issues.apache.org/jira/browse/GEODE-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9947: Fix Version/s: 1.15.0 > Implement LINDEX > > > Key: GEODE-9947 > URL: https://issues.apache.org/jira/browse/GEODE-9947 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Implement the [LINDEX|https://redis.io/commands/lindex] command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10066:
-
Fix Version/s: 1.15.0
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
>
[jira] [Updated] (GEODE-10008) Avoid possible EntryDestroyedException error in wan-copy region command when entry destroyed in partitioned region
[ https://issues.apache.org/jira/browse/GEODE-10008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10008: - Fix Version/s: 1.15.0 > Avoid possible EntryDestroyedException error in wan-copy region command when > entry destroyed in partitioned region > -- > > Key: GEODE-10008 > URL: https://issues.apache.org/jira/browse/GEODE-10008 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: blocks-1.15.0, needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > When the wan-copy region command is executed over a partitioned region, it is > possible that sometimes an EntryDestroyedException error is found if, while > reading the entries from the region, one of them is destroyed. > The error has been seen sometimes when running the following test: > WanCopyRegionCommandDUnitTest. > testSuccessfulExecutionWhileRunningOpsOnRegion(true, true). > > Log of the error: > Multiple Failures (2 failures) > org.opentest4j.AssertionFailedError: [ Member | > Status | Message > -- | -- | > --- > alberto-dell(421543):41010 | ERROR | Execution failed. Error: > org.apache.geode.cache.EntryDestroyedException: 26 > alberto-dell(421504):41009 | OK | Entries copied: 2,977 > alberto-dell(421598):41011 | OK | Entries copied: 3,042 > ] > expected: OK > but was: ERROR > 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-vm6.log' at line 1883 > [error 2022/02/01 08:58:59.046 CET tid=99] > Exception occurred attempting to wan-copy region > java.util.concurrent.ExecutionException: > org.apache.geode.cache.EntryDestroyedException: 26 > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at > org.apache.geode.cache.wan.internal.WanCopyRegionFunctionService.execute(WanCopyRegionFunctionService.java:90) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunctionInService(WanCopyRegionFunction.java:163) > at > org.apache.geode.management.internal.cli.functions.WanCopyRegionFunction.executeFunction(WanCopyRegionFunction.java:157) > at > org.apache.geode.management.cli.CliFunction.execute(CliFunction.java:37) > at > org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:447) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444) > at > org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:379) > at > org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120) > at java.lang.Thread.run(Thread.java:748) > Caused by: org.apache.geode.cache.EntryDestroyedException: 26 > at > org.apache.geode.internal.cache.NonTXEntry.basicGetEntry(NonTXEntry.java:62) > at > org.apache.geode.internal.cache.NonTXEntry.getRegion(NonTXEntry.java:119) > at > org.apache.geode.internal.cache.NonTXEntry.hashCode(NonTXEntry.java:157) > at java.util.HashMap.hash(HashMap.java:340) > at java.util.HashMap.put(HashMap.java:613) > at java.util.HashSet.add(HashSet.java:220) > at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) > at java.util.Iterator.forEachRemaining(Iterator.java:116) > at > java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801) > at > java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:647) > at > java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:272) > at java.util.HashMap$KeySpliterator.forEachRemaining(HashMap.java:1580) > at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482) > at >
[jira] [Updated] (GEODE-10080) Upgrade Jedis client in benchmark tests to 4.1.1
[ https://issues.apache.org/jira/browse/GEODE-10080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10080: - Fix Version/s: 1.15.0 > Upgrade Jedis client in benchmark tests to 4.1.1 > > > Key: GEODE-10080 > URL: https://issues.apache.org/jira/browse/GEODE-10080 > Project: Geode > Issue Type: Task > Components: benchmarks, redis >Reporter: Eric Zoerner >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Upgrade Jedis client in benchmark tests to 4.1.1. This is necessary in order > to benchmark support for Redis 6.0 in Geode for Redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9845) CI failure: Multiple tests in OutOfMemoryDUnitTest failed with ConnectException
[
https://issues.apache.org/jira/browse/GEODE-9845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9845:
Fix Version/s: 1.15.0
> CI failure: Multiple tests in OutOfMemoryDUnitTest failed with
> ConnectException
> ---
>
> Key: GEODE-9845
> URL: https://issues.apache.org/jira/browse/GEODE-9845
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
> Attachments: PXL_20220114_205141950.MP.jpg,
> PXL_20220114_205147440.jpg, PXL_20220114_205152268.jpg,
> PXL_20220114_205156514.jpg
>
>
> 4 tests in OutOfMemoryDUnitTest failed with `java.net.ConnectException:
> Connection refused`.
> {noformat}
> OutOfMemoryDUnitTest > shouldAllowDeleteOperations_afterThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting throwable message:
> "No more cluster attempts left."
> to contain:
> "OOM command not allowed"
> but did not.
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisClusterMaxAttemptsException: No more
> cluster attempts left.
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:156)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.set(JedisCluster.java:293)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.setRedisKeyAndValue(OutOfMemoryDUnitTest.java:228)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$addMultipleKeys$5(OutOfMemoryDUnitTest.java:212)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:62)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:877)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeys(OutOfMemoryDUnitTest.java:210)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillMemory(OutOfMemoryDUnitTest.java:201)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowDeleteOperations_afterThresholdReached(OutOfMemoryDUnitTest.java:166)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> 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.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
> 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:43)
> at
>
[jira] [Updated] (GEODE-10072) api-check does not link to the japicmp report anymore
[ https://issues.apache.org/jira/browse/GEODE-10072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10072: - Fix Version/s: 1.15.0 > api-check does not link to the japicmp report anymore > - > > Key: GEODE-10072 > URL: https://issues.apache.org/jira/browse/GEODE-10072 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > it seems that CI still expects the report in geode-assembly, but the build > now puts it in geode-server-all -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10000) Avoid gfsh stop gateway sender error when stopped a second time
[ https://issues.apache.org/jira/browse/GEODE-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-1: - Fix Version/s: 1.15.0 > Avoid gfsh stop gateway sender error when stopped a second time > --- > > Key: GEODE-1 > URL: https://issues.apache.org/jira/browse/GEODE-1 > Project: Geode > Issue Type: Bug > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > After changing the implementation of the "stop gateway sender" command to be > parallel, when it is invoked a second time it fails with the following error: > Error while processing command Reason : > Task java.util.concurrent.FutureTask@513d30f9 rejected from > java.util.concurrent.ThreadPoolExecutor@85189b9[Terminated, pool size = 0, > active threads = 0, queued tasks = 0, completed tasks = 2] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10002) Remove from documentation obligation for parallel gateway sender to share disk store with region
[ https://issues.apache.org/jira/browse/GEODE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10002: - Fix Version/s: 1.15.0 > Remove from documentation obligation for parallel gateway sender to share > disk store with region > > > Key: GEODE-10002 > URL: https://issues.apache.org/jira/browse/GEODE-10002 > Project: Geode > Issue Type: Bug > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > As a result of GEODE-7997, it was documented that "the persisted data from a > parallel gateway sender must go to the same disk store as used by the region, > because parallel gateway sender queues must be colocated with their regions > to operate correctly.". > As stated in the Activity in the original ticket by Dan Smith, "The only > issue with separating the data into two separate disk stores is that manually > deleting the files for just one of the disk stores could cause a hang on > startup looking for the missing disk store. We recommend keeping all of the > colocated data together." > Given that the current statement in the documentation adds a non compatible > change to previous versions and also that the given restriction prevents from > the independent management of the disk used by the region and by the parallel > gateway sender queues it is proposed to change the statement from an > obligation to a recommendation giving the reasons for it or completely > removing the obligation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10082) Duplicate values found in DSCode enums
[ https://issues.apache.org/jira/browse/GEODE-10082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10082: - Fix Version/s: 1.15.0 > Duplicate values found in DSCode enums > -- > > Key: GEODE-10082 > URL: https://issues.apache.org/jira/browse/GEODE-10082 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The following snippet appears in DSCode.hpp: > ``` > CacheableEnum = 94, > ClientProxyMembershipId = 38, > CacheableUserData = 39, > CacheableUserData2 = 38, > CacheableUserData4 = 37, > PDX = 93, > PDX_ENUM = 94, > InterestResultPolicy = 37, > }; > ``` > `CacheableEnum` is the name of the class that geode-native uses for > `PDX_ENUM`, it should not exist as an enum value. `ClientProxyMembershipId`, > `InternalDistributedMember`, and `InterestResultPolicy` are > `DataSerializableFixedId` values, and belong in that enum rather than DSCode. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10013) Remove unused code in Geode for Redis tests
[ https://issues.apache.org/jira/browse/GEODE-10013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10013: - Fix Version/s: 1.15.0 > Remove unused code in Geode for Redis tests > --- > > Key: GEODE-10013 > URL: https://issues.apache.org/jira/browse/GEODE-10013 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Ray Ingles >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Several Geode for Redis tests contain redundant server.stop() calls and > unnecessary "canStoreBinaryData" tests. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10032) Redis Command Registry Needs to Include Data Structure
[ https://issues.apache.org/jira/browse/GEODE-10032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10032: - Fix Version/s: 1.15.0 > Redis Command Registry Needs to Include Data Structure > -- > > Key: GEODE-10032 > URL: https://issues.apache.org/jira/browse/GEODE-10032 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Not all Redis commands are associated with a data structure. For the > commands that are, we need to know which data structure that command is > associated with. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9807) Gfsh stop gateway sender command in parallel
[ https://issues.apache.org/jira/browse/GEODE-9807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9807: Fix Version/s: 1.15.0 > Gfsh stop gateway sender command in parallel > > > Key: GEODE-9807 > URL: https://issues.apache.org/jira/browse/GEODE-9807 > Project: Geode > Issue Type: Improvement > Components: gfsh, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Currently, the gfsh stop gateway sender command stops serially the gateway > sender on each server. > The higher the number of Geode servers in the system, the longer the command > will take. > This process can take very long specially in deployments with a lot of Geode > servers and this can be aggravated if the receiving side is not available > (connections to the remote site are timing out). > It is proposed to implement the stopping of gateway senders in gfsh in > parallel just as it is done by the start gateway sender gfsh command. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
[ https://issues.apache.org/jira/browse/GEODE-10071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10071: - Fix Version/s: 1.15.0 > Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand > > > Key: GEODE-10071 > URL: https://issues.apache.org/jira/browse/GEODE-10071 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0, 1.16.0 >Reporter: Udo Kohlmeyer >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > There is a cyclical dependency between the Command and the implementing > function for the Wan copy feature. > Logically, the command needs to have a dependency on the function. > The error messages currently defined in the Command class need to be moved to > the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10114) NullPointerException is logged if create index when cache is closing.
[ https://issues.apache.org/jira/browse/GEODE-10114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10114: - Fix Version/s: 1.15.0 > NullPointerException is logged if create index when cache is closing. > - > > Key: GEODE-10114 > URL: https://issues.apache.org/jira/browse/GEODE-10114 > Project: Geode > Issue Type: Bug > Components: querying >Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The following NPE is logged when creating index if cache is closing at the > same time. > [info 2020/02/19 02:28:46.140 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index idRangeEntryIndex on > region /__PR/_B__QueryRegion0_46 with exception: > java.lang.NullPointerException > [info 2020/02/19 02:28:46.198 PST bridgegemfire3_host1_29240 Message Processor 1> tid=0x2e] Failed to create index > statusCompactRangeEntryIndex on region /__PR/_B__QueryRegion0_46 with > exception: java.lang.NullPointerException -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9949) Implement LPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9949: Fix Version/s: 1.15.0 > Implement LPUSHX > > > Key: GEODE-9949 > URL: https://issues.apache.org/jira/browse/GEODE-9949 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Implement the [LPUSHX|https://redis.io/commands/lpushx] command. > > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10111) add COMMITWATCHERS for self-service opt-in/opt-out of automated commit message review
[ https://issues.apache.org/jira/browse/GEODE-10111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-10111: - Fix Version/s: 1.15.0 > add COMMITWATCHERS for self-service opt-in/opt-out of automated commit > message review > - > > Key: GEODE-10111 > URL: https://issues.apache.org/jira/browse/GEODE-10111 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > previously opt-in and unsubscribe required a dev list email, and this led to > complaints > this self-serve mechanism achieves the same goal of a public record of opt-in > requests, without adding noise to the dev list -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10049) Redis tests should include the entire error response message rather than just the error type
[
https://issues.apache.org/jira/browse/GEODE-10049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10049:
-
Fix Version/s: 1.15.0
> Redis tests should include the entire error response message rather than just
> the error type
>
>
> Key: GEODE-10049
> URL: https://issues.apache.org/jira/browse/GEODE-10049
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> Currently many tests look for substrings of error messages, rather than the
> error message as a whole. This has in the past led to cases where the Geode
> for Redis Module's error messages have not precisely matched those of native
> Redis.
> For example, if the test is:
> {code:java}
> assertThatThrownBy(
> () -> jedis.hsetnx(string_key, field, "something else"))
> .isInstanceOf(JedisDataException.class)
> .hasMessageContaining("WRONGTYPE");{code}
> instead we should probably look for the full error message that native Redis
> puts out:
> {code:java}
> .hasMessage("WRONGTYPE Operation against a key holding the wrong kind of
> value"){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10018) Remove tx flag from Redis SetOptions
[
https://issues.apache.org/jira/browse/GEODE-10018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10018:
-
Fix Version/s: 1.15.0
> Remove tx flag from Redis SetOptions
>
>
> Key: GEODE-10018
> URL: https://issues.apache.org/jira/browse/GEODE-10018
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Reporter: Jens Deppe
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> A recent change ([https://github.com/apache/geode/pull/7321)] consolidated
> the logic for transactional operations, avoiding the need for individual data
> structs and commands to take different code paths to account for delta
> changes vs tx contexts.
>
> The MSET command still contains this older approach which can now be removed.
> Practically, we can remove the {{SetOptions.inTransaction}} field and all
> logic surrounding this flag.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10104) Create parallel gateway sender with dispatcher-threads value greater then 1 is failing
[
https://issues.apache.org/jira/browse/GEODE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10104:
-
Fix Version/s: 1.15.0
> Create parallel gateway sender with dispatcher-threads value greater then 1
> is failing
> --
>
> Key: GEODE-10104
> URL: https://issues.apache.org/jira/browse/GEODE-10104
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.14.0
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When creating parallel gateway sender with attribute dispatcher-threads
> greater then 1, command is rejected with error "{color:#6a8759}Must specify
> --order-policy when --dispatcher-threads is larger than 1.{color}".
>
> But according to documentation:
> You cannot configure the {{order-policy}} for a parallel event queue, because
> parallel queues cannot preserve event ordering for regions. Only the ordering
> of events for a given partition (or in a given queue of a distributed region)
> can be preserved.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10052) CI Failure: OutOfMemoryDUnitTest tests of Publish command fail expecting exception that was not thrown
[
https://issues.apache.org/jira/browse/GEODE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-10052:
-
Fix Version/s: 1.15.0
> CI Failure: OutOfMemoryDUnitTest tests of Publish command fail expecting
> exception that was not thrown
> --
>
> Key: GEODE-10052
> URL: https://issues.apache.org/jira/browse/GEODE-10052
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Hale Bales
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> There were three failures within a couple of days. They are all in publish
> tests.
> {code:java}
> OutOfMemoryDUnitTest > shouldReturnOOMError_forPublish_whenThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeysToServer1UntilOOMExceptionIsThrown(OutOfMemoryDUnitTest.java:357)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:344)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldReturnOOMError_forPublish_whenThresholdReached(OutOfMemoryDUnitTest.java:210)
> {code}
> {code:java}
> OutOfMemoryDUnitTest > shouldReturnOOMError_forPublish_whenThresholdReached
> FAILED
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.addMultipleKeysToServer1UntilOOMExceptionIsThrown(OutOfMemoryDUnitTest.java:357)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:344)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldReturnOOMError_forPublish_whenThresholdReached(OutOfMemoryDUnitTest.java:210)
> {code}
> {code:java}
> OutOfMemoryDUnitTest > shouldAllowPublish_afterDroppingBelowCriticalThreshold
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a org.apache.geode.redis.OutOfMemoryDUnitTest
> Expecting code to raise a throwable within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
> 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.redis.OutOfMemoryDUnitTest.shouldAllowPublish_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:328)
> Caused by:
> java.lang.AssertionError:
> Expecting code to raise a throwable.
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$shouldAllowPublish_afterDroppingBelowCriticalThreshold$36(OutOfMemoryDUnitTest.java:328)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9892) Create Infrastructure for Redis Lists
[ https://issues.apache.org/jira/browse/GEODE-9892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9892: Fix Version/s: 1.15.0 > Create Infrastructure for Redis Lists > - > > Key: GEODE-9892 > URL: https://issues.apache.org/jira/browse/GEODE-9892 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Create the infrastructure for supporting Redis Lists including: > * Use of the appropriate underlying Java collection > * Implementing the [LPUSH|https://redis.io/commands/lpush] Command > * Implementing the [LRANGE|https://redis.io/commands/lrange] command > +Acceptance Critera+ > The LPUSH and LRANGE commands have been implemented with appropriate unit > testing. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9991) SSL protocol and cipher preferences are ignored when endpoint verification is enabled.
[
https://issues.apache.org/jira/browse/GEODE-9991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-9991:
Fix Version/s: 1.15.0
> SSL protocol and cipher preferences are ignored when endpoint verification is
> enabled.
> --
>
> Key: GEODE-9991
> URL: https://issues.apache.org/jira/browse/GEODE-9991
> Project: Geode
> Issue Type: Bug
> Components: core, security
>Affects Versions: 1.12.8, 1.12.9, 1.13.7, 1.13.8, 1.14.3, 1.14.4, 1.15.0,
> 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> When SSL endpoint verification is enabled the configuration for protocols and
> ciphers reverts to the {{SSLContext}}'s client mode defaults. This can result
> in difficulty upgrade the JDK when the newer JDK may use different defaults
> for client and server mode SSL.
> Oracle JDK 1.8.0_u261 and OpenJDK 1.8.0_u272 replaced the SSL implementation
> with a back port from Java 11. This changed the default server protocols from
> {{[SSLv2Hello, TLSv1, TLSv1.1, TLSv1.2]}} to {{[TLSv1.3,TLSv1.2,SSLv2Hello]}}
> and client to {{[TLSv1.3,TLSv1.2]}}. With this bug the the server protocols
> get reset to the client protocols dropping support for the {{SSLv2Hello}}
> protocol, which is the first priority protocol by default in the old JDK.
> The result is a failure to handshake with the following exception:
> {{javax.net.ssl.SSLHandshakeException: SSLv2Hello is not enabled}}
> To reproduce you need to have endpoint validation enabled on your SSL
> configuration. Set your protocols to `any`. Start 1st locator with JDK older
> than 1.8.0_u261. Start 2nd locator with JDK at least as new as JDK
> 1.8.0_u272.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9998: Fix Version/s: 1.15.0 > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0, 1.16.0 >Reporter: Jens Deppe >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed which will affect a > lot of test code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9955) Implement RPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristen reassigned GEODE-9955: -- Assignee: Kristen > Implement RPUSHX > > > Key: GEODE-9955 > URL: https://issues.apache.org/jira/browse/GEODE-9955 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Kristen >Priority: Major > > Implement the [RPUSHX|https://redis.io/commands/rpushx] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9955) Implement RPUSHX
[ https://issues.apache.org/jira/browse/GEODE-9955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales reassigned GEODE-9955: - Assignee: (was: Hale Bales) > Implement RPUSHX > > > Key: GEODE-9955 > URL: https://issues.apache.org/jira/browse/GEODE-9955 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Implement the [RPUSHX|https://redis.io/commands/rpushx] command. > > +Acceptance Criteria+ > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10129:
--
Assignee: Dale Emery
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Labels: GeodeOperationAPI Java17 (was: Java17)
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-10128:
--
Assignee: Dale Emery
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Labels: GeodeOperationAPI Java17 pull-request-available (was: Java17
pull-request-available)
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10130: --- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507860#comment-17507860
]
Steve Sienkowski commented on GEODE-9696:
-
Flaky test seen in this CI run:
[https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14110469]
{noformat}
ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.13.0] FAILED
org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple
Failures (2 failures)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$496/0x00010041c440.call
in VM 0 running on Host
heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d.c.apachegeode-ci.internal
with 4 VMs
java.lang.AssertionError: Suspicious strings were written to the log
during this run.
---
Found suspect string in 'dunit_suspect-locator.log' at line 194
[fatal 2022/03/16 01:25:57.215 UTC tid=51] This
member is no longer in the membership view. My ID is
heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d(18914:locator):57667
and the new view is
View[heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d(28607):57668|544]
members:
[heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d(28607):57668{lead},
heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d(28635):57669] crashed:
[heavy-lifter-071112d8-71bd-539e-bcf6-81240ef2242d(18914:locator):57667]
---
{noformat}
> CI Failure: ClientAuthenticationDUnitTest >
> testCredentialsForNotifications[1.8.0] FAILED
> -
>
> Key: GEODE-9696
> URL: https://issues.apache.org/jira/browse/GEODE-9696
> Project: Geode
> Issue Type: Bug
> Components: membership, security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Donal Evans
>Priority: Major
>
> Link:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
> Stacktrace:
> {noformat}
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
> in VM 1 running on Host
> heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.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:473)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
> Caused by:
> java.lang.AssertionError: Got unexpected exception when starting peer
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> at
> org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
> at
> org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
> at
> org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
> at
> org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at
[jira] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10128:
---
Labels: Java17 pull-request-available (was: Java17)
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17, pull-request-available
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10046) bump dependencies in 1.16
[ https://issues.apache.org/jira/browse/GEODE-10046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507816#comment-17507816 ] ASF subversion and git services commented on GEODE-10046: - Commit 9ff27b37cf5cc7a97700c64c77a28eefe8ae9d4a in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9ff27b3 ] GEODE-10046: Bump 3rd-party dependency versions (#7434) 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. Dependency bumps in this batch: * Bump awaitility from 4.1.1 to 4.2.0 * Bump cargo from 1.9.9 to 1.9.10 * Bump classgraph from 4.8.138 to 4.8.141 * Bump guava from 31.0.1-jre to 31.1-jre * Bump jackson from 2.13.1 to 2.13.2 * Bump jetty from 9.4.44.v20210927 to 9.4.45.v20220203 * Bump junit-pioneer from 1.5.0 to 1.6.1 * Bump log4j from 2.17.1 to 2.17.2 * Bump micrometer-core from 1.8.2 to 1.8.3 * Bump mockito from 4.3.1 to 4.4.0 * Bump spring from 5.3.15 to 5.3.16 * Bump spring-boot-starter from 2.6.3 to 2.6.4 * Bump spring-ldap from 2.3.5.RELEASE to 2.3.6.RELEASE * Bump spring-security from 5.6.1 to 5.6.2 * Bump spring-session from 2.6.1 to 2.6.2 * Bump tomcat from 9.0.58 to 9.0.59 > bump dependencies in 1.16 > - > > Key: GEODE-10046 > URL: https://issues.apache.org/jira/browse/GEODE-10046 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > until support/1.16 is cut, periodically check for and switch to latest > version of 3rd-party dependencies. this will extend the shelf-life of > eventual Geode 1.16 release and hopefully reduce bugs and cve exposure, or at > least give a smaller delta if there is later a cve found that we need to > patch for -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507803#comment-17507803 ] ASF subversion and git services commented on GEODE-9809: Commit 41f9ec58b519d63d224bf128732b89a490e48451 in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=41f9ec5 ] GEODE-9809: stop monitoring of destroyed regions (#7113) * GEODE-9809: stop monitoring of destroyed regions > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. > In our test, in cluster with 50 servers, we have leader persisted partitioned > region with more than 1000 buckets, and colocated 2 persisted regions. If we > consecutively create and destroy child regions, memory leak is observed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-9809. - Fix Version/s: 1.16.0 Resolution: Fixed > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: persistence >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. > In our test, in cluster with 50 servers, we have leader persisted partitioned > region with more than 1000 buckets, and colocated 2 persisted regions. If we > consecutively create and destroy child regions, memory leak is observed. -- 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=1750#comment-1750
]
ASF subversion and git services commented on GEODE-10127:
-
Commit fb5c9c197226b705cf049bbe561e35d197dcf57e in geode's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb5c9c1 ]
GEODE-10127: Reverts changes from GEODE-8955. (#7450)
Reverts 516bdc9322e1068c14e901879a7fb4afeac9b181
The change from toString to marshal results in the loss of hostname-for-clients
or bind-address as the name sent remotely.
> 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, 1.16.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-8955) WAN location service uses DistributedLocatorId.toString() to represent a locator
[
https://issues.apache.org/jira/browse/GEODE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507778#comment-17507778
]
ASF subversion and git services commented on GEODE-8955:
Commit fb5c9c197226b705cf049bbe561e35d197dcf57e in geode's branch
refs/heads/develop from Jacob Barrett
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fb5c9c1 ]
GEODE-10127: Reverts changes from GEODE-8955. (#7450)
Reverts 516bdc9322e1068c14e901879a7fb4afeac9b181
The change from toString to marshal results in the loss of hostname-for-clients
or bind-address as the name sent remotely.
> WAN location service uses DistributedLocatorId.toString() to represent a
> locator
>
>
> Key: GEODE-8955
> URL: https://issues.apache.org/jira/browse/GEODE-8955
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Kevo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This code in LocatorHelper, and probably code in other parts of the WAN
> location service, uses DistributionLocatorId.toString() to track whether
> other locators have the WAN location service available. It should use the
> DistributionLocatorId.marshal() method instead. We should never use the
> toString() representation of an object in this way as it may change over time.
>
> {code:java}
> private static void addServerLocator(Integer distributedSystemId,
> LocatorMembershipListener locatorListener, DistributionLocatorId locator)
> {
> ConcurrentHashMap> allServerLocatorsInfo =
> (ConcurrentHashMap>)
> locatorListener.getAllServerLocatorsInfo();
> Set locatorsSet = new CopyOnWriteHashSet();
> locatorsSet.add(locator.toString());
> Set existingValue =
> allServerLocatorsInfo.putIfAbsent(distributedSystemId, locatorsSet);
> if (existingValue != null) {
> if (!existingValue.contains(locator.toString())) {
> existingValue.add(locator.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10130: - Labels: GeodeOperationAPI (was: needsTriage) > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10130: Assignee: Eric Shu > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: needsTriage > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10130) cq destroy event in replicate region can be missing
[ https://issues.apache.org/jira/browse/GEODE-10130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10130: -- Labels: needsTriage (was: ) > cq destroy event in replicate region can be missing > > > Key: GEODE-10130 > URL: https://issues.apache.org/jira/browse/GEODE-10130 > Project: Geode > Issue Type: Bug > Components: cq >Affects Versions: 1.12.0, 1.13.0, 1.14.4, 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > In geode, cq event for replicated region are cached so that when destroy > event comes in, we can just use cached value to determine if a client need > the cq event (instead of evaluate the query again for performance). > However, there is a synchronization issue in > ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find > the cached event. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10130) cq destroy event in replicate region can be missing
Eric Shu created GEODE-10130: Summary: cq destroy event in replicate region can be missing Key: GEODE-10130 URL: https://issues.apache.org/jira/browse/GEODE-10130 Project: Geode Issue Type: Bug Components: cq Affects Versions: 1.13.0, 1.12.0, 1.14.4, 1.15.0 Reporter: Eric Shu In geode, cq event for replicated region are cached so that when destroy event comes in, we can just use cached value to determine if a client need the cq event (instead of evaluate the query again for performance). However, there is a synchronization issue in ServerCQResultsCacheReplicateRegionImpl that could cause geode failed to find the cached event. -- 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=17507772#comment-17507772
]
Dale Emery commented on GEODE-10119:
Two changes:
* Change {{test.gradle}} to launch test JVMs with the requisite opens/exports.
See https://issues.apache.org/jira/browse/GEODE-10128 for the list of
opens/exports that I currently know about.
* Change {{ProcessManager}} to forward the test JVM's opens/exports to any
child VM it launches. https://issues.apache.org/jira/browse/GEODE-10129 for how
to query the current JVM's opens/exports.
Those changes may suffice. I learned of this issue in a private experimental
branch that includes other changes, so perhaps I've missed a necessary step.
> 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
>Priority: Major
> Labels: Java17, needsTriage
>
> 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
>
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Labels: Java17 (was: )
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> # Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
> the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10129) Forward module-related options when launching test subprocesses
[
https://issues.apache.org/jira/browse/GEODE-10129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10129:
---
Description:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages. (See
https://issues.apache.org/jira/browse/GEODE-10128)
# Query the {{--add-opens}} and {{--add-exports}} that were used to launch the
current JVM. This can be done by calling
{{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
was:
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages.
# Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
the current JVM. This can be done by calling
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
> Forward module-related options when launching test subprocesses
> ---
>
> Key: GEODE-10129
> URL: https://issues.apache.org/jira/browse/GEODE-10129
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> Several tests and test helpers launch JVMs to run Geode code. For tests to
> run properly on JDK 17, that code must open or export the packages needed by
> the code that will run in the JVMs.
> Such helpers include:
> - {{GfshCommandRule}}
> - {{ProcessManager}} for DUnit tests.
> - {{ServerContainer}} for Jetty/Tomcat session tests.
> Also, {{ServerLauncherDUnitTest}} launches JVMs via a {{{}ProcessBuilder{}}}.
> A simple way to support opening and exporting the required packages is:
> # Assume that the current JVM opened and exported all required packages.
> (See https://issues.apache.org/jira/browse/GEODE-10128)
> # Query the {{--add-opens}} and {{--add-exports}} that were used to launch
> the current JVM. This can be done by calling
> {{{}ManagementFactory.getRuntimeMXBean().getInputArguments(){}}}, then
> filtering the list to retain only the {{--add-opens}} and {{--add-exports}}
> options.
> # Add those options when launching a subprocess.
> It would be useful to query and perform the current JVM a single place. I
> propose a static method: {{{}JavaModuleHelper.getJvmModuleOptions(){}}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10129) Forward module-related options when launching test subprocesses
Dale Emery created GEODE-10129:
--
Summary: Forward module-related options when launching test
subprocesses
Key: GEODE-10129
URL: https://issues.apache.org/jira/browse/GEODE-10129
Project: Geode
Issue Type: Improvement
Components: tests
Affects Versions: 1.16.0
Reporter: Dale Emery
Several tests and test helpers launch JVMs to run Geode code. For tests to run
properly on JDK 17, that code must open or export the packages needed by the
code that will run in the JVMs.
Such helpers include:
- {{GfshCommandRule}}
- {{ProcessManager}} for DUnit tests.
- {{ServerContainer}} for Jetty/Tomcat session tests.
Also, {{ServerLauncherDUnitTest}} launches JVMs via a \{{ProcessBuilder}}.
A simple way to support opening and exporting the required packages is:
# Assume that the current JVM opened and exported all required packages.
# Query the {{\--add-opens}} and {{\--add-exports}} that were used to launch
the current JVM. This can be done by calling
{{ManagementFactory.getRuntimeMXBean().getInputArguments()}}, then filtering
the list to retain only the {{\--add-opens}} and {{\--add-exports}} options.
# Add those options when launching a subprocess.
It would be useful to query and perform the current JVM a single place. I
propose a static method: {{JavaModuleHelper.getJvmModuleOptions()}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0
blocks-1.15.0 pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
>
[jira] [Updated] (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:all-tabpanel
]
Jacob Barrett updated GEODE-10127:
--
Labels: blocks-1.15.0 pull-request-available (was: blocks-1.15.0
needsTriage pull-request-available)
> 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, 1.16.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] [Updated] (GEODE-10128) Open and export additional packages when running tests on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-10128:
---
Labels: Java17 (was: )
> Open and export additional packages when running tests on JDK 17
>
>
> Key: GEODE-10128
> URL: https://issues.apache.org/jira/browse/GEODE-10128
> Project: Geode
> Issue Type: Improvement
> Components: ci, tests
>Affects Versions: 1.16.0
>Reporter: Dale Emery
>Priority: Major
> Labels: Java17
>
> JDK 17 throws exceptions when code attempts certain kinds of access to
> packages that are not opened or exported by their modules. JDK 11 issued
> warnings in these cases.
> When Gradle launches test JVMs, it must open and export the packages that
> will be accessed by product and test code during the tests. We currently
> configure a few packages in {{{}test.gradle{}}}. To support JDK 17, we must
> open and export additional packages.
> Additional packages to open (via {{{}--add-opens{}}}):
> - java.base/java.lang
> - java.base/java.nio
> - java.base/java.text
> - java.base/java.util
> - java.base/java.util.concurrent
> - java.base/java.util.concurrent.atomic
> - java.base/java.util.concurrent.locks
> - java.base/javax.net.ssl
> - java.base/sun.security.ssl
> - java.base/sun.util.locale
> - java.rmi/sun.rmi.transport
> Additional packages to export (via {{{}--add-opens{}}}):
> - java.base/jdk.internal.util.random
> - java.base/sun.nio.ch
> - java.base/sun.security.x509
> - java.management/com.sun.jmx.remote.security
> We may discover additional packages to open/export as we run more tests under
> JDK 17, and as we change product and test code.
> Note that different JDKs define different {{jdk.internal}} subpackages. For
> example:
> - JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
> - On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
> Windows and macOS JDKs do not.
> We have a few options for dealing with the differing {{jdk.internal}}
> packages:
> - Configure which packages we open/export depending on the JDK
> implementation.
> - Open all of these packages on all JDK platforms and versions (JDK 9 or
> higher). This will produce warnings when we open/export a package that does
> not exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10128) Open and export additional packages when running tests on JDK 17
Dale Emery created GEODE-10128:
--
Summary: Open and export additional packages when running tests on
JDK 17
Key: GEODE-10128
URL: https://issues.apache.org/jira/browse/GEODE-10128
Project: Geode
Issue Type: Improvement
Components: ci, tests
Affects Versions: 1.16.0
Reporter: Dale Emery
JDK 17 throws exceptions when code attempts certain kinds of access to packages
that are not opened or exported by their modules. JDK 11 issued warnings in
these cases.
When Gradle launches test JVMs, it must open and export the packages that will
be accessed by product and test code during the tests. We currently configure a
few packages in {{{}test.gradle{}}}. To support JDK 17, we must open and export
additional packages.
Additional packages to open (via {{{}--add-opens{}}}):
- java.base/java.lang
- java.base/java.nio
- java.base/java.text
- java.base/java.util
- java.base/java.util.concurrent
- java.base/java.util.concurrent.atomic
- java.base/java.util.concurrent.locks
- java.base/javax.net.ssl
- java.base/sun.security.ssl
- java.base/sun.util.locale
- java.rmi/sun.rmi.transport
Additional packages to export (via {{{}--add-opens{}}}):
- java.base/jdk.internal.util.random
- java.base/sun.nio.ch
- java.base/sun.security.x509
- java.management/com.sun.jmx.remote.security
We may discover additional packages to open/export as we run more tests under
JDK 17, and as we change product and test code.
Note that different JDKs define different {{jdk.internal}} subpackages. For
example:
- JDK 17 has {{{}jdk.internal.util.random{}}}, but JDK 11 does not.
- On Linux, JDK 11 and 17 have {{{}jdk.internal.platform.cgroupv1{}}}, but
Windows and macOS JDKs do not.
We have a few options for dealing with the differing {{jdk.internal}} packages:
- Configure which packages we open/export depending on the JDK implementation.
- Open all of these packages on all JDK platforms and versions (JDK 9 or
higher). This will produce warnings when we open/export a package that does not
exist.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (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:all-tabpanel
]
ASF GitHub Bot updated GEODE-10127:
---
Labels: blocks-1.15.0 needsTriage pull-request-available (was:
blocks-1.15.0 needsTriage)
> 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, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage, 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] [Updated] (GEODE-10122) With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When Encrypted Data Limit is Reached
[ https://issues.apache.org/jira/browse/GEODE-10122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-10122: -- Labels: blocks-1.15.0 pull-request-available (was: pull-request-available) > With TLSv1.3 and GCM-based cipher (the default), P2P Messaging Fails When > Encrypted Data Limit is Reached > - > > Key: GEODE-10122 > URL: https://issues.apache.org/jira/browse/GEODE-10122 > Project: Geode > Issue Type: Bug > Components: messaging >Affects Versions: 1.13.7, 1.14.3, 1.15.0, 1.16.0 >Reporter: Bill Burcham >Assignee: Bill Burcham >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Attachments: patch-P2PMessagingConcurrencyDUnitTest.txt > > > TLSv1.3 introduced [1] the ability to set per-algorithm limits on symmetric > key usage lifetimes. Once a certain number of bytes have been encrypted, a > KeyUpdate post-handshake message [2] is sent. > With default settings, on Liberica JDK 11, Geode's P2P framework will > negotiate TLSv1.3 with the TLS_AES_256_GCM_SHA384 cipher suite. Geode P2P > messaging will eventually fail, with a "Tag mismatch!" IOException in shared > ordered receivers, after a session has been in heavy use for days. > We have not see this failure on TLSv1.2. > The implementation of TLSv1.3 in the Java runtime provides a security > property [3] to configure the encrypted data limit. The attached patch to > P2PMessagingConcurrencyDUnitTest configures the limit large enough that the > test makes it through the (P2P) TLS handshake but small enough so that the > "Tag mismatch!" exception is encountered less than a minute later. > The bug is caused by Geode’s NioSslEngine class’ ignorance of the > “rehandshaking” phase of the TLS protocol [4]: > Creation - ready to be configured. > Initial handshaking - perform authentication and negotiate communication > parameters. > Application data - ready for application exchange. > *Rehandshaking* - renegotiate communications parameters/authentication; > handshaking data may be mixed with application data. > Closure - ready to shut down connection. > Geode's tcp.Connection and NioSslEngine classes (particularly wrap() and > unwrap()), as they are currently implemented, fail to fully attend to the > handshake status from javax.net.ssl.SSLEngine. As a result these Geode > classes fail to respond to the KeyUpdate message, resulting in the "Tag > mismatch!" IOException. > When that exception is encountered, the Connection is destroyed and a new one > created in its place. But users of the old Connection, waiting for > acknowledgements, will never receive them. This can result in cluster-wide > hangs. > [1] [https://datatracker.ietf.org/doc/html/rfc8446#section-5.5] > [2] > [https://www.ibm.com/docs/en/sdk-java-technology/8?topic=handshake-post-messages] > > [3] > [https://docs.oracle.com/en/java/javase/11/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-B970ADD6-1E9F-4C18-A26E-0679B50CC946] > [4] [https://www.ibm.com/docs/en/sdk-java-technology/7.1?topic=sslengine-] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 blocks-1.15.0 pull-request-available (was:
blocks-1.15.0 pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
>
[jira] [Updated] (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:all-tabpanel
]
Jacob Barrett updated GEODE-10127:
--
Labels: blocks-1.15.0 needsTriage (was: needsTriage)
> 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, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> 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] [Updated] (GEODE-10066) SSL handshake failures on 1 locator prevents connection pool from trying other locators
[
https://issues.apache.org/jira/browse/GEODE-10066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacob Barrett updated GEODE-10066:
--
Labels: blocks-1.15.0 pull-request-available (was: pull-request-available)
> SSL handshake failures on 1 locator prevents connection pool from trying
> other locators
> ---
>
> Key: GEODE-10066
> URL: https://issues.apache.org/jira/browse/GEODE-10066
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> If an {{SSLException}} is thrown when handshaking with a locator the
> exception is wrapped in an {{IllegalStateException}} that is not caught by
> the connection pool, the stack is blown, and no connections can be
> established. If not wrapped the connection pool will properly try the next
> locator.
> The {{SSLExceptions}} are wrapped in at least
> {{TcpClient.getServerVersion()}} but other locations may exist in this path.
> This method throws {{IOException}} and the {{SSLExceptions}} extend
> {{IOExceptions}} so they should not be wrapped. It probably makes sense to
> split the concern of socket connection from determining the server version in
> {{TcpClient.getServerVersion()}}.
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.2.8.12 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at
> sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:594)
> at
> org.apache.geode.internal.net.SCAdvancedSocketCreator.connect(SCAdvancedSocketCreator.java:83)
> at
> org.apache.geode.distributed.internal.tcpserver.ClusterSocketCreatorImpl.connect(ClusterSocketCreatorImpl.java:96)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:246)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:151)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:227)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:217)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:264)
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:176)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:211)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:282)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:940)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:464)
> at
> org.apache.geode.cache.wan.internal.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:105)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:66)
> at
>
[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=17507720#comment-17507720
]
Jacob Barrett commented on GEODE-10127:
---
The change from toString to marshal results in the loss of
{{hostname-for-clients}} or {{bind-address}} as the name sent remotely. This
change had no tests associated with it. All current tests affected by this bug
don't fail because we don't don't do any multi-homed or split-horizon DNS
testing.
> 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, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> 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] [Assigned] (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:all-tabpanel
]
Jacob Barrett reassigned GEODE-10127:
-
Assignee: Jacob Barrett
> 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, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> 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] [Updated] (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:all-tabpanel
]
Alexander Murmann updated GEODE-10127:
--
Labels: needsTriage (was: )
> 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, 1.16.0
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage
>
> 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] [Created] (GEODE-10127) Incorrect locator hostname used in remote locator connections
Jacob Barrett created GEODE-10127:
-
Summary: 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, 1.16.0
Reporter: Jacob Barrett
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-288) Remove deprecated Admin API
[ https://issues.apache.org/jira/browse/GEODE-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507707#comment-17507707 ] ASF subversion and git services commented on GEODE-288: --- Commit b129e58e4a20cda67ff80a728c85e095d491419c in geode's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b129e58 ] GEODE-288: Adds @Deprecated annotation to old admin service. (#7430) The public API and some internal classes had doclet tags but not class level @Deprecated annotations. > Remove deprecated Admin API > --- > > Key: GEODE-288 > URL: https://issues.apache.org/jira/browse/GEODE-288 > Project: Geode > Issue Type: Sub-task > Components: jmx >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Priority: Major > Labels: deprecated, pull-request-available > > The Admin API (com.gemstone.gemfire.admin) and old JMX Agent have been > deprecated since GemFire 7.0. The Admin API was retired in favor of using the > new Management JMX API (com.gemstone.gemfire.management) and GFSH. > #1) move some Admin classes used internally by non-Admin code: > move com.gemstone.gemfire.admin.BackupStatus > move com.gemstone.gemfire.admin.OperationCancelledException > move com.gemstone.gemfire.admin.RegionNotFoundException > move > com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.backupAllMembers > move > com.gemstone.gemfire.admin.internal.AdminDistributedSystemImpl.compactAllDiskStores > move com.gemstone.gemfire.admin.internal.FinishBackupRequest > move com.gemstone.gemfire.admin.internal.FlushToDiskRequest > move com.gemstone.gemfire.admin.internal.InetAddressUtil > move com.gemstone.gemfire.admin.internal.PrepareBackupRequest > #2) move com.gemstone.gemfire.admin to > com.gemstone.gemfire.internal.admin.api (temporarily) > #3) remove com.gemstone.gemfire.cache.* usage of admin > #4) remove com.gemstone.gemfire.distributed.* usage of admin > #5) remove com.gemstone.gemfire.internal.* usage of admin (except for > internal.admin.*) > #6) remove com.gemstone.gemfire.management.* usage of admin > #7) remove com.gemstone.gemfire.internal.admin.api if possible > #8) remove unused classes from com.gemstone.gemfire.internal.admin.* > Breakdown by package and class: > com.gemstone.gemfire > --change DataSerializer to use moved RegionNotFoundException > com.gemstone.gemfire.cache > com.gemstone.gemfire.cache.persistence > com.gemstone.gemfire.cache.util > --remove com.gemstone.gemfire.cache.util.UniversalMembershipListenerAdapter > com.gemstone.gemfire.distributed > --remove Admin API from javadocs in Locator and DistributedSystem > com.gemstone.gemfire.distributed.internal > --remove > com.gemstone.gemfire.distributed.internal.DistributionManager.createHealthMonitor > --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitor > --remove remove com.gemstone.gemfire.distributed.internal.HealthMonitorImpl > --change > com.gemstone.gemfire.distributed.internal.InternalDistributedSystem.hasAlertListenerFor > to not use AlertLevel > com.gemstone.gemfire.internal > --remove DSFIDFactory support for admin messages > --remove com.gemstone.gemfire.admin.jmx.internal.AgentLauncher from > GemFireUtilLauncher > --change MigrationServer to use moved InetAddressUtil > --change SocketCreator to use moved InetAddressUtil > --remove SystemAdmin.backup > --remove SystemAdmin.compactAllDiskStores > --remove SystemAdmin.shutDownAll > --remove SystemAdmin.listMissingDiskStores > --remove SystemAdmin.revokeMissingDiskStores > com.gemstone.gemfire.internal.cache > --replace use of com.gemstone.gemfire.admin.OperationCancelledException > --remove use of > com.gemstone.gemfire.admin.internal.SystemMemberCacheEventProcessor > com.gemstone.gemfire.internal.cache.partitioned > --replace use of com.gemstone.gemfire.admin.OperationCancelledException > com.gemstone.gemfire.internal.cache.snapshot > --replace use of com.gemstone.gemfire.admin.RegionNotFoundException > com.gemstone.gemfire.internal.tools.gfsh.app.command.task > --reimplement PartitionedRegionAttributeTask > com.gemstone.gemfire.internal.tools.gfsh.util > --reimplement RegionUtil > com.gemstone.gemfire.management.internal.beans > --change DistributedSystemBridge to use moved classes > com.gemstone.gemfire.management.internal.cli.commands > --change DiskStoreCommands to use moved classes > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is unreliable during
restarts, as it takes some time for the locator to accumulate this information.
So during the startup of the servers locator will send CreateRegionFunction to
servers since it couldn't detect that region already exists using the
DistributedRegionMXBean service. In most scenarios, the server will reject that
function. The only case the server will execute the function is when using the
local cache.xml configuration in addition to the cluster configuration. It
seems that processing local cache.xml creates a time gap on the server that
will accept CreateRegionFunction, although the region is already available in
the cluster configuration.
Slution:
In addition to checks done against the DistributedRegionMXBean information, do
the same checks against cluster configuration (if used) stored in locators.
This way, the "create region" command is rejected immediately by the locator
instead of later by the servers.
was:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is unreliable during
restarts, as it takes some time for the locator to accumulate this information.
So during the startup of the servers locator will send CreateRegionFunction to
servers since it couldn't detect that region already exists using the
DistributedRegionMXBean service. In most scenarios, the server will reject that
function. The only case the server will execute the function is when using the
local cache.xml configuration in addition to the cluster configuration. It
seems that processing local cache.xml creates a time gap on the server that
will accept CreateRegionFunction, although the region is already available in
the cluster configuration.
Solution:
In addition to checks done against the DistributedRegionMXBean information, do
the same checks against cluster configuration (if used) stored in locators.
This way, the "create region" command is rejected immediately by the locator
instead of later by the servers.
was:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is unreliable during
restarts, as it takes some time for the locator to accumulate this information.
So during the startup of the servers locator will send CreateRegionFunction to
servers since it couldn't detect that region already exists using the
DistributedRegionMXBean service. In most scenarios, the server will reject that
function. The only case the server will execute the function is when using the
local cache.xml configuration in addition to the cluster configuration. It
seems that processing local cache.xml creates a time gap on the server that
will accept CreateRegionFunction, although the region is already available in
the cluster configuration.
The solution would be to perform required checks against cluster configuration
stored on locators when using cluster configuration in addition to checks done
using DistributedRegionMXBean.
was:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. So during the startup of the servers locator will send
CreateRegionFunction to servers since it couldn't detect that region already
exists using the DistributedRegionMXBean service. In most scenarios, the server
will reject that function. The only case the server will execute the function
is when using the local cache.xml configuration in addition to the cluster
configuration. It seems that processing local cache.xml creates a time gap on
the server that will accept CreateRegionFunction, although the region is
already available in the cluster configuration and will be applied to that
server.
*The solution would* be to perform required checks against cluster
configuration stored on locators when using cluster configuration in addition
to checks done using DistributedRegionMXBean.
was:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period when servers restart even though region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when restarted again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is unreliable during
restarts, as it takes some time for the locator to accumulate this information.
So during the startup of the servers locator will send CreateRegionFunction to
servers since it couldn't detect that region already exists using the
DistributedRegionMXBean service. In most scenarios, the server will reject that
function. The only case the server will execute the function is when using the
local cache.xml configuration in addition to the cluster configuration. It
seems that processing local cache.xml creates a time gap on the server that
will accept CreateRegionFunction, although the region is already available in
the cluster configuration.
The solution would be to perform required checks against cluster configuration
stored on locators when using cluster configuration in addition to checks done
using DistributedRegionMXBean.
was:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when stated again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region and servers throw the exception
*org.apache.geode.cache.RegionExistsException* when stated again:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. So during the startup of the servers locator will send
CreateRegionFunction to servers since it couldn't detect that region already
exists using the DistributedRegionMXBean service. In most scenarios, the server
will reject that function. The only case the server will execute the function
is when using the local cache.xml configuration in addition to the cluster
configuration. It seems that processing local cache.xml creates a time gap on
the server that will accept CreateRegionFunction, although the region is
already available in the cluster configuration and will be applied to that
server.
The solution would be to perform required checks against cluster configuration
stored on locators when using cluster configuration in addition to checks done
using DistributedRegionMXBean.
was:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. So during the startup of the servers locator will send
CreateRegionFunction to servers since it couldn't detect that region already
exists using the DistributedRegionMXBean service. In most scenarios, the server
will reject that function. The only case the server will execute the function
is when using the local cache.xml configuration in addition to the cluster
configuration. It seems that processing local cache.xml creates a time gap on
the server that will accept CreateRegionFunction, although the region is
already available in the cluster configuration and will be applied to that
server.
The solution would be to perform required checks against cluster configuration
stored on locators when using cluster configuration in addition to checks done
using DistributedRegionMXBean.
was:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains a duplicated region, so servers throw the following
exception *org.apache.geode.cache.RegionExistsException* at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. It makes more sense to perform required checks against cluster
configuration stored on locators when using cluster configuration.
was:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains duplicated region, and because of that, servers throw
the following exception at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. It makes more sense to
[jira] [Updated] (GEODE-10123) Multiple execution of Create region command results with duplicated region in cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-10123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakov Varenina updated GEODE-10123:
---
Description:
We have observed that sometimes the "create region" command executes
successfully during period servers restart event thought region is already
available in the cluster configuration. When this happens, cluster
configuration contains duplicated region, and because of that, servers throw
the following exception at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. It makes more sense to perform required checks against cluster
configuration stored on locators when using cluster configuration.
was:
We have observed that sometimes the same "create region" command executes more
than once successfully during servers restart and results in the duplicated
definition of the same region in the cluster configuration. When this happens,
servers throw the following exception at startup:
{code:java}
Exception in thread "main" org.apache.geode.cache.CacheXmlException: While
parsing XML, caused by org.xml.sax.SAXException: A CacheException was thrown
while parsing XML.
org.apache.geode.cache.RegionExistsException: /regionTest
at
org.apache.geode.internal.cache.xmlcache.CacheXmlParser.parse(CacheXmlParser.java:267)
at
org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4119)
at
org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:208)
at
org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1426)
at
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1391)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
at
org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
at
org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
at
org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:892)
at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:807)
at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
Caused by: org.xml.sax.SAXException: A CacheException was thrown while parsing
XML.
{code}
CreateRegionCommand checks whether there is already an existing region using
the DistributedRegionMXBean service. This service is sometimes unreliable
during restarts, as it takes some time for the locator to accumulate this
information. It makes more sense to perform required checks against cluster
configuration stored on locators
[jira] [Commented] (GEODE-10100) release 1.13.8
[ https://issues.apache.org/jira/browse/GEODE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507357#comment-17507357 ] ASF subversion and git services commented on GEODE-10100: - Commit f2b9b903b9878d715b1ccb4382cb57549018d290 in geode's branch refs/heads/develop from Dick Cavender [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f2b9b90 ] GEODE-10100: Replace 1.13.7 with 1.13.8 as old version (#7447) Replace 1.13.7 with 1.13.8 in old versions on develop to enable rolling upgrade tests from 1.13.8 The serialization version has not changed between 1.13.7 and 1.13.8, so there should be no need to keep both > release 1.13.8 > -- > > Key: GEODE-10100 > URL: https://issues.apache.org/jira/browse/GEODE-10100 > Project: Geode > Issue Type: Task > Components: release >Reporter: Dick Cavender >Priority: Major > Labels: pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0, 1.16.0 > > > Release to incorporate GEODE-10093 -- This message was sent by Atlassian Jira (v8.20.1#820001)
