[jira] [Commented] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110050#comment-17110050 ] ASF GitHub Bot commented on GEODE-7971: --- albertogpz commented on pull request #4928: URL: https://github.com/apache/geode/pull/4928#issuecomment-630039797 > I've reviewed the doc components and I have some changes to propose. Most are concerned with grammar and format. The only technical one is to replace references to the `is-parallel` property with the `parallel` property. > I'm not sure how best to submit these, as it would be good to have them reviewed before checking them in. The most convenient method for me is the output of a `git diff`, so here goes. If you'd like me to incorporate the material in some other way (e.g. push my local commit to the feature branch) please let me know. > > diff --git a/geode-docs/reference/topics/cache_xml.html.md.erb b/geode-docs/reference/topics/cache_xml.html.md.erb > index 4d9e859550..39e3d66962 100644 > --- a/geode-docs/reference/topics/cache_xml.html.md.erb > +++ b/geode-docs/reference/topics/cache_xml.html.md.erb > @@ -298,8 +298,8 @@ Configures a gateway sender to distribute region events to another <%=vars.produ > group-transaction-events Boolean value to ensure that all the events of a transaction are sent in the same batch, i.e., they are never spread across different batches. - > > Only allowed to be set on gateway senders with `is-parallel` attribute set to false and `dispatcher-threads` attribute equal to 1 or on gatewaysenders with `is-parallel` attribute set to true. > - > > Note that in order to work for a transaction, the regions to which the transaction events belong must be replicated by the same set of senders with this flag enabled. > + > > Only allowed to be set on gateway senders with the `parallel` attribute set to false and `dispatcher-threads` attribute equal to 1, or on gateway senders with the `parallel` attribute set to true. > + > > Note: In order to work for a transaction, the regions to which the transaction events belong must be replicated by the same set of senders with this flag enabled. > false diff --git a/geode-docs/tools_modules/gfsh/command-pages/create.html.md.erb b/geode-docs/tools_modules/gfsh/command-pages/create.html.md.erb index 6140c6f79c..771412a96d 100644 --- a/geode-docs/tools_modules/gfsh/command-pages/create.html.md.erb +++ b/geode-docs/tools_modules/gfsh/command-pages/create.html.md.erb @@ -635,8 +635,8 @@ create gateway-sender --id=value --remote-distributed-system-id=value \-\-group-transaction-events Boolean value to ensure that all the events of a transaction are sent in the same batch, i.e., they are never spread across different batches. - > > Only allowed to be set on gateway senders with `is-parallel` attribute set to false and `dispatcher-threads` attribute equal to 1 or on gatewaysenders with `is-parallel` attribute set to true. > - > > Note that in order to work for a transaction, the regions to which the transaction events belong must be replicated by the same set of senders with this flag enabled. > + > > Only allowed to be set on gateway senders with the `parallel` attribute set to false and `dispatcher-threads` attribute equal to 1, or on gatewaysenders with the `parallel` attribute set to true. > + > > Note: In order to work for a transaction, the regions to which the transaction events belong must be replicated by the same set of senders with this flag enabled. > false diff --git a/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb b/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb index 64a129009f..be8dfafeb9 100644 --- a/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb +++ b/geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb @@ -171,7 +171,7 @@ When using a multi-site configuration, you choose which data regions to share be > > * Regions using the same parallel gateway sender ID must be colocated. > > > -- If any gateway sender configured for the region has the `group-transaction-events` flag set to true, then the regions involved in transactions must all have the same gateway senders with this flag set to true configured. This requires careful configuration of regions with gateway-senders according to the transactions expected in the system. > +- If any gateway sender configured for the region has the `group-transaction-events` flag set to true, then the regions involved in transactions must all have the same gateway senders configured with this flag set to true. This requires careful configuration of regions with
[jira] [Commented] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110475#comment-17110475 ] ASF GitHub Bot commented on GEODE-8122: --- dschneider-pivotal merged pull request #5122: URL: https://github.com/apache/geode/pull/5122 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Major > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110476#comment-17110476 ] ASF subversion and git services commented on GEODE-8122: Commit 4c12d70a14e2745d72bb2f11ed9c1687d128c892 in geode's branch refs/heads/develop from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c12d70 ] GEODE-8122: Update Geode Redis API docs (#5122) Update the GeodeRedisServer java doc and the Redis API for Geode documentation. > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Major > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-7474) NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
[
https://issues.apache.org/jira/browse/GEODE-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reopened GEODE-7474:
> NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
> --
>
> Key: GEODE-7474
> URL: https://issues.apache.org/jira/browse/GEODE-7474
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/1665]
>
> {noformat}
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest >
> testNetSearchFailoverFromReplicate FAILED
> 19:13:08java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 19:13:08Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2385
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.977 GMT thread 2> tid=207] Uncaught exception in thread Thread[Geode Failure
> Detection thread 2,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@1274aba9
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:477)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:461)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 19:13:08 at java.lang.Thread.run(Thread.java:748)
> 19:13:08
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2399
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.976 GMT thread 4> tid=226] Uncaught exception in thread Thread[Geode Failure
> Detection thread 4,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@143de298
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:477)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:461)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
[jira] [Updated] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8122: --- Priority: Minor (was: Major) > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Minor > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7474) NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
[
https://issues.apache.org/jira/browse/GEODE-7474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110479#comment-17110479
]
Mark Hanson commented on GEODE-7474:
Failed again.
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/176
> NetSearchMessagingDUnitTest.testNetSearchFailoverFromReplicate
> --
>
> Key: GEODE-7474
> URL: https://issues.apache.org/jira/browse/GEODE-7474
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.11.0
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Labels: flaky
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/mhansonp-mhanson-mass-test-ru-main/jobs/DistributedTestOpenJDK8/builds/1665]
>
> {noformat}
> org.apache.geode.internal.cache.NetSearchMessagingDUnitTest >
> testNetSearchFailoverFromReplicate FAILED
> 19:13:08java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 19:13:08Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2385
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.977 GMT thread 2> tid=207] Uncaught exception in thread Thread[Geode Failure
> Detection thread 2,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@1274aba9
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:477)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:461)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 19:13:08 at java.lang.Thread.run(Thread.java:748)
> 19:13:08
> 19:13:08
> ---
> 19:13:08Found suspect string in log4j at line 2399
> 19:13:08
> 19:13:08[fatal 2019/11/18 03:13:06.976 GMT thread 4> tid=226] Uncaught exception in thread Thread[Geode Failure
> Detection thread 4,5,RMI Runtime]
> 19:13:08java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$226/1317859019@143de298
> rejected from java.util.concurrent.ThreadPoolExecutor@100274c7[Shutting
> down, pool size = 3, active threads = 3, queued tasks = 0, completed tasks =
> 7]
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> 19:13:08 at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1295)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1478)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:477)
> 19:13:08 at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$0(GMSHealthMonitor.java:461)
[jira] [Resolved] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8122. Resolution: Fixed > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Minor > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110480#comment-17110480
]
Mark Hanson commented on GEODE-6645:
Failed again
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/175#A
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Assignee: Kirk Lund
>Priority: Major
> Labels: CI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(Ru
[jira] [Commented] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110482#comment-17110482
]
Mark Hanson commented on GEODE-6222:
Failed again
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/173]
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nabarun Nag resolved GEODE-8029. Resolution: Fixed > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:869) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:786) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:716) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:236) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos reopened GEODE-8029: --- > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:869) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:786) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:716) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:236) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8144) endpoint identification in servers is not working
Bruce J Schuchardt created GEODE-8144:
-
Summary: endpoint identification in servers is not working
Key: GEODE-8144
URL: https://issues.apache.org/jira/browse/GEODE-8144
Project: Geode
Issue Type: Bug
Components: membership, messaging
Reporter: Bruce J Schuchardt
If you enable endpoint identification in a server the server will not start.
It will log exceptions like this:
{noformat}
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problemCaused
by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem at
sun.security.ssl.Alerts.getSSLException(Alerts.java:198) at
sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1729) at
sun.security.ssl.Handshaker.fatalSE(Handshaker.java:333) at
sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325) at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082) at
sun.security.ssl.Handshaker$1.run(Handshaker.java:1015) at
sun.security.ssl.Handshaker$1.run(Handshaker.java:1012) at
java.security.AccessController.doPrivileged(Native Method) at
sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1504) at
org.apache.geode.internal.net.NioSslEngine.handleBlockingTasks(NioSslEngine.java:225)
at org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:185)
... 27 moreCaused by: java.security.cert.CertificateException: No subject
alternative names matching IP address 10.118.26.62 found at
sun.security.util.HostnameChecker.matchIP(HostnameChecker.java:168) at
sun.security.util.HostnameChecker.match(HostnameChecker.java:94) at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:462)
at
sun.security.ssl.X509TrustManagerImpl.checkIdentity(X509TrustManagerImpl.java:442)
at
sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:261)
at
sun.security.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:144)
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1675)
... 35 more {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-8144:
--
Description:
If you enable endpoint identification in a server the server will not start.
It will log exceptions like this:
{noformat}
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
at
sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
at
sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
at
org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
at
org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
at
org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
at
org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
at
org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
at
org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
at
org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
at
org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
at
org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)
at
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
at src.EntryConsumer.initialize(EntryConsumer.java:69)
at src.EntryConsumer.main(EntryConsumer.java:340)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:198)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1729)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:333)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:325)
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1688)
at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:226)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1082)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1015)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:1012)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1504)
at
org.apache.geode.internal.net.NioSslEngine.handleBlockingTasks(NioSslEngine.java:225)
at
org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:185)
... 27 more
Caused by: java.security.cert.CertificateException: No subject alternative
names matching IP address 10.118.26.62 found
at sun.security.util.HostnameChecker.matc
[jira] [Commented] (GEODE-8144) endpoint identification in servers is not working
[
https://issues.apache.org/jira/browse/GEODE-8144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110531#comment-17110531
]
Bruce J Schuchardt commented on GEODE-8144:
---
I've tested this with 1.7, 1.8, 1.9 and 1.10 as well as on develop and
apparently this has never worked in servers. There are unit tests for endpoint
identification but they don't exercise the code paths taken in the TLS
implementation when the server socket is on a different host than the client
socket.
We need to set the "sni servername" in the client's SSLParameters in order to
tell the SSLEngine's hostname verification algorithm the name of the server to
which we intend to connect.
Bill found this relevant page on an IBM website:
[ssl
parameters|https://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.security.component.80.doc/security-component/jsse2Docs/sslparameters.html]
> endpoint identification in servers is not working
> -
>
> Key: GEODE-8144
> URL: https://issues.apache.org/jira/browse/GEODE-8144
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> If you enable endpoint identification in a server the server will not start.
> It will log exceptions like this:
>
> {noformat}
> javax.net.ssl.SSLHandshakeException: General SSLEngine problem
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1566)
> at
> sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:545)
> at
> sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1217)
> at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1185)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:471)
> at
> org.apache.geode.internal.net.NioSslEngine.handshake(NioSslEngine.java:158)
> at
> org.apache.geode.internal.net.SocketCreator.handshakeSSLSocketChannel(SocketCreator.java:597)
> at
> org.apache.geode.internal.tcp.Connection.createIoFilter(Connection.java:1731)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1167)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1004)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:288)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:392)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:571)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:800)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:451)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:268)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:510)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1986)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1623)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at src.EntryConsumer.initialize(EntryConsumer.java:69)
> at src.EntryConsumer.main(EntryConsumer.java:340)
> Caused by: javax.net.ssl.SSLHandshakeException: General SSLE
[jira] [Updated] (GEODE-8145) Add Redis Configuration Properties to gemfire_properties.html
[ https://issues.apache.org/jira/browse/GEODE-8145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8145: --- Priority: Minor (was: Major) > Add Redis Configuration Properties to gemfire_properties.html > - > > Key: GEODE-8145 > URL: https://issues.apache.org/jira/browse/GEODE-8145 > Project: Geode > Issue Type: Improvement > Components: docs, redis >Reporter: Sarah Abbey >Priority: Minor > > redis-password, redis-bind-address, and redis-port need to be added to this > page -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8145) Add Redis Configuration Properties to gemfire_properties.html
Sarah Abbey created GEODE-8145: -- Summary: Add Redis Configuration Properties to gemfire_properties.html Key: GEODE-8145 URL: https://issues.apache.org/jira/browse/GEODE-8145 Project: Geode Issue Type: Improvement Components: docs, redis Reporter: Sarah Abbey redis-password, redis-bind-address, and redis-port need to be added to this page -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110596#comment-17110596 ] ASF GitHub Bot commented on GEODE-7971: --- albertogpz commented on a change in pull request #4928: URL: https://github.com/apache/geode/pull/4928#discussion_r426877956 ## File path: geode-core/src/main/java/org/apache/geode/cache/wan/GatewaySender.java ## @@ -153,6 +155,13 @@ .getInteger(GeodeGlossary.GEMFIRE_PREFIX + "gateway-connection-retry-interval", 1000) .intValue(); + /** + * Number of times to retry to get events for a transaction from the gateway sender queue + */ + int GET_TRANSACTION_EVENTS_FROM_QUEUE_RETRIES = + Integer.getInteger(GeodeGlossary.GEMFIRE_PREFIX + "get-transaction-events-from-queue-retries", Review comment: I > Apache Geode is an open-source repo, so nothing is truly hidden from users. However, there are many examples of properties that intentionally go un-mentioned in the User Guide. Such a property should be briefly commented in code, indicating the use for which it is intended and what its limitations are, so curious browsing developers won't get themselves into trouble. I have added a longer description in the comments for the property in my last commit. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8137) Implement loadService on JBossModuleService
[ https://issues.apache.org/jira/browse/GEODE-8137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Johnsn reassigned GEODE-8137: - Assignee: Patrick Johnsn > Implement loadService on JBossModuleService > --- > > Key: GEODE-8137 > URL: https://issues.apache.org/jira/browse/GEODE-8137 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement loadService to load implementations of a given interface from JBoss > Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8043) Create JBoss-Modules ModuleService Implementation - loadModule
[ https://issues.apache.org/jira/browse/GEODE-8043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110653#comment-17110653 ] ASF GitHub Bot commented on GEODE-8043: --- lgtm-com[bot] commented on pull request #5081: URL: https://github.com/apache/geode/pull/5081#issuecomment-630465422 This pull request **introduces 1 alert** when merging e388fbcae5f0ca2026197714df7883d8485cc266 into 353192ee8600a4ee94c661d4ac22fd2c8bf34702 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-966a83f44d04ee1956ee0d57012fa1c6f59bf54b) **new alerts:** * 1 for Potential input resource leak This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create JBoss-Modules ModuleService Implementation - loadModule > -- > > Key: GEODE-8043 > URL: https://issues.apache.org/jira/browse/GEODE-8043 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Implement the loadModule method of the ModuleService interface using > JBoss-Modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110670#comment-17110670 ] ASF subversion and git services commented on GEODE-8122: Commit 4c12d70a14e2745d72bb2f11ed9c1687d128c892 in geode's branch refs/heads/feature/GEODE-8067 from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c12d70 ] GEODE-8122: Update Geode Redis API docs (#5122) Update the GeodeRedisServer java doc and the Redis API for Geode documentation. > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Minor > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8133) Fix devBuild gradle target
[ https://issues.apache.org/jira/browse/GEODE-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110663#comment-17110663 ] ASF subversion and git services commented on GEODE-8133: Commit 32a01771f8bea9190f39aff30c85a93908a8342c in geode's branch refs/heads/feature/GEODE-8067 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=32a0177 ] GEODE-8133: Fix task chaining for 'devBuild' (#5118) > Fix devBuild gradle target > -- > > Key: GEODE-8133 > URL: https://issues.apache.org/jira/browse/GEODE-8133 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > devBuild only runs spotlessApply instead of compilation tasks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8035) Parallel Disk Store Recovery when Cluster Restarts
[ https://issues.apache.org/jira/browse/GEODE-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110666#comment-17110666 ] ASF subversion and git services commented on GEODE-8035: Commit 0d602cc9d0b89cf875b883f53af912c2ddc4d26a in geode's branch refs/heads/feature/GEODE-8067 from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d602cc ] GEODE-8035: Parallel Disk Store Recovery when Cluster Restarts (#5014) * Add parallel stream for disk store recovery * Replace synchronized block with CountDownLatch * Add the new system property parallelDiskStoreRecovery * Add documentation of the new system property Authored-by: Jianxia Chen > Parallel Disk Store Recovery when Cluster Restarts > -- > > Key: GEODE-8035 > URL: https://issues.apache.org/jira/browse/GEODE-8035 > Project: Geode > Issue Type: Improvement >Reporter: Jianxia Chen >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI > > Currently, when Geode cluster restarts, the disk store recovery is > serialized. When all regions share the same disk store, the restart process > is time consuming. To improve the performance, different regions can use > different disk stores with different disk controllers. And adding parallel > disk store recovery. This is expected to significantly reduce the time to > restart Geode cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110672#comment-17110672 ] ASF subversion and git services commented on GEODE-8041: Commit bfad4a25b02fb3cf77bb52dbf614eb1d46cd0e41 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bfad4a2 ] GEODE-8041 - Create ManagementService interface. (#5062) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface. The ManagementService will configure > and start Geode (create a Cache given some configuration properties) after > the BootstrappingService has bootstrapped the environment and loaded the > relevant modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8096) redeployingParentClassDoesNotCauseSubclassIncompatibilities encounters ClassNotFoundException exception
[
https://issues.apache.org/jira/browse/GEODE-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110667#comment-17110667
]
ASF subversion and git services commented on GEODE-8096:
Commit 334e24fa559733b8824222f266e6df6cc5531f29 in geode's branch
refs/heads/feature/GEODE-8067 from Nabarun Nag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=334e24f ]
GEODE-8096: Providing unique names for the JARs in the tests (#5119)
* Same JAR names among tests in the same folder may be deleted by clean up from
previously run tests.
* Undeploying the JARs after test execution to remove the files from
the test environment so they don't run out of space.
> redeployingParentClassDoesNotCauseSubclassIncompatibilities encounters
> ClassNotFoundException exception
> ---
>
> Key: GEODE-8096
> URL: https://issues.apache.org/jira/browse/GEODE-8096
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Nabarun Nag
>Priority: Major
> Labels: caching-applications
> Fix For: 1.14.0
>
>
> JUnit test failed in this CI run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/134#A
> {code}
> org.apache.geode.internal.ClassPathLoaderJUnitTest >
> redeployingParentClassDoesNotCauseSubclassIncompatibilities FAILED
> java.lang.ClassNotFoundException: jddunit.function.classB
> at
> org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:186)
> at
> org.apache.geode.internal.ClassPathLoader$1.loadClass(ClassPathLoader.java:366)
> at
> org.apache.geode.internal.ClassPathLoaderJUnitTest.redeployingParentClassDoesNotCauseSubclassIncompatibilities(ClassPathLoaderJUnitTest.java:242)
> {code}
> I ran it 100 times in IntelliJ with no failures. On the theory that maybe we
> ran out of disk I visually traced through the paths dealing w/ (jar) files
> and didn't see anywhere where the product might have been swallowing
> exceptions. So I don't know what went wrong.
> Marked component as serialization because this is testing loading a Jar file
> that redefines a class which was the base class (of a derived class) loaded
> previously from a different jar file. Seems like the point of all that is
> mainly to support users updating their jar files without restarting their
> JVMs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8078) Exceptions in locator logs when hitting members REST endpoint
[
https://issues.apache.org/jira/browse/GEODE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110661#comment-17110661
]
ASF subversion and git services commented on GEODE-8078:
Commit a235c7c4ea2474d6fe347326ef888c7c10daffb6 in geode's branch
refs/heads/feature/GEODE-8067 from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a235c7c ]
GEODE-8078: log and report error at the correct place. (#5111)
* For get operation, if cache is not ready, just don't report any runtime
information
* do not log the CacheClosedException
> Exceptions in locator logs when hitting members REST endpoint
> -
>
> Key: GEODE-8078
> URL: https://issues.apache.org/jira/browse/GEODE-8078
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI
>
> I'm seeing the following exceptions in locator logs when I try to hit the
> REST endpoint /management/v1/members/\{id} before the member has finished
> starting up. The reason I need to do this is because I have a program that is
> polling that endpoint to wait until the member is online. Ideally these
> errors would not show up in logs, but instead be reflected in the status code
> of the REST response.
> {quote}[error 2020/04/06 22:05:59.086 UTC tid=0x31] class
> org.apache.geode.cache.CacheClosedException cannot be cast to class
> org.apache.geode.management.runtime.RuntimeInfo
> (org.apache.geode.cache.CacheClosedException and
> org.apache.geode.management.runtime.RuntimeInfo are in unnamed module of
> loader 'app')
> java.lang.ClassCastException: class
> org.apache.geode.cache.CacheClosedException cannot be cast to class
> org.apache.geode.management.runtime.RuntimeInfo
> (org.apache.geode.cache.CacheClosedException and
> org.apache.geode.management.runtime.RuntimeInfo are in unnamed module of
> loader 'app')
> at
> org.apache.geode.management.internal.api.LocatorClusterManagementService.list(LocatorClusterManagementService.java:417)
> at
> org.apache.geode.management.internal.api.LocatorClusterManagementService.get(LocatorClusterManagementService.java:434)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController.getMember(MemberManagementController.java:50)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController$$FastClassBySpringCGLIB$$3634e452.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:769)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:747)
> at
> org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:69)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:747)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:689)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController$$EnhancerBySpringCGLIB$$2893b195.getMember()
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:888)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:793)
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapt
[jira] [Commented] (GEODE-8069) release script fixes
[ https://issues.apache.org/jira/browse/GEODE-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110668#comment-17110668 ] ASF subversion and git services commented on GEODE-8069: Commit fff985340fb652231dbac5b959386c0334ebfb11 in geode's branch refs/heads/feature/GEODE-8067 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fff9853 ] GEODE-8069: fix release script issues (#5050) fix versions and other issues encountered creating the support branches * clarify which new version to add to Jira * don't enable metrics by default, since they don't work * always create a starting build number for proper version cmp in concourse * do not use less as pager during release scripts, as it is confusing to need to press Q to continue * mention that prepare_rc can be re-run without commenting out completed steps, if desired * GEODE-8016: switch from -SNAPSHOT to -build.n * revise semantic version selector to use for geode-examples to find geode * ensure we are in correct dir for executing sub-scripts * dont fail if temp commit has already been reverted > release script fixes > > > Key: GEODE-8069 > URL: https://issues.apache.org/jira/browse/GEODE-8069 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > fix issues encountered in 1.14.0 release experience -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8094) Create HA test to ensure Spring Boot sessions expire correctly
[ https://issues.apache.org/jira/browse/GEODE-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110662#comment-17110662 ] ASF subversion and git services commented on GEODE-8094: Commit 4fff1f9fde1b1401c68722c015f65267bf5da971 in geode's branch refs/heads/feature/GEODE-8067 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4fff1f9 ] GEODE-8094: Create HA test to ensure Spring Boot sessions expire correctly (#5079) Co-authored-by: Murtuza Boxwala Co-authored-by: Raymond Ingles Co-authored-by: Jens Deppe > Create HA test to ensure Spring Boot sessions expire correctly > -- > > Key: GEODE-8094 > URL: https://issues.apache.org/jira/browse/GEODE-8094 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Fix For: 1.14.0 > > > Write a high level test to ensure that sessions created by Spring Boot expire > correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8130) Change the way redis uses geode regions to save memory and fix race conditions
[ https://issues.apache.org/jira/browse/GEODE-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110664#comment-17110664 ] ASF subversion and git services commented on GEODE-8130: Commit e084aa4bdaed4d626e559fec4e7e64e1fbf93755 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e084aa4 ] GEODE-8130: use a single region for redis Sets and Hashes (#5120) * Replaced replicated metaRegion with a partitioned dataRegion. Currently the dataRegion is used the same way as the metaRegion except for sets and hashes which store their actual data in it. * Exception handling now correctly deals with FunctionException * Disabled a test until GEODE-8127 if fixed. * Now uses the ByteArrayWrapper as the key on the meta region and the locks map instead of using a String. Since a ByteArrayWrapper is used as the key in the data region this will end up saving memory. * Found a problem with redis dynamic region management. Some of the code was executing when we added a new set or hash to the metaDataRegion. It was only ignoring STRING and HLL. This caused some extra memory to be used for every redis set/hash. Now the dynamic region code is only used for lists and sortedSet. * This commit has some TODO comments of what looks like a bug in the dynamic region code when a new server is started. It looks like the new server will not create already existing dynamic regions. We could test this by starting one server, create a LIST, then start another server, and then shutdown the first server. Does the LIST still exist? If we change them not to use dynamic regions then this issue will go away. > Change the way redis uses geode regions to save memory and fix race conditions > -- > > Key: GEODE-8130 > URL: https://issues.apache.org/jira/browse/GEODE-8130 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Currently the geode redis implementation uses a replicate region to hold > every redis key as the region key (as a String object) and the region value > is an enum describing the type. Another partitioned regioni is used to also > store the redis key as the region key (as a ByteArrayWrapper object) and the > region value is an object that is basically a Set or HashMap. > This uses extra memory, the replicate does not scale well, is slower > (updating two regions is slower than one region), and trying to update two > regions to hold the same logical redis "key" has race conditions which can > lead to inconsistent data. > The solution is to have a single partitioned region that can hold multiple > types of data (sets, hashes, strings, lists, etc). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110665#comment-17110665 ] ASF subversion and git services commented on GEODE-8127: Commit e084aa4bdaed4d626e559fec4e7e64e1fbf93755 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e084aa4 ] GEODE-8130: use a single region for redis Sets and Hashes (#5120) * Replaced replicated metaRegion with a partitioned dataRegion. Currently the dataRegion is used the same way as the metaRegion except for sets and hashes which store their actual data in it. * Exception handling now correctly deals with FunctionException * Disabled a test until GEODE-8127 if fixed. * Now uses the ByteArrayWrapper as the key on the meta region and the locks map instead of using a String. Since a ByteArrayWrapper is used as the key in the data region this will end up saving memory. * Found a problem with redis dynamic region management. Some of the code was executing when we added a new set or hash to the metaDataRegion. It was only ignoring STRING and HLL. This caused some extra memory to be used for every redis set/hash. Now the dynamic region code is only used for lists and sortedSet. * This commit has some TODO comments of what looks like a bug in the dynamic region code when a new server is started. It looks like the new server will not create already existing dynamic regions. We could test this by starting one server, create a LIST, then start another server, and then shutdown the first server. Does the LIST still exist? If we change them not to use dynamic regions then this issue will go away. > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8016) Replace Maven SNAPSHOT with enumerated build-id artifacts
[ https://issues.apache.org/jira/browse/GEODE-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110669#comment-17110669 ] ASF subversion and git services commented on GEODE-8016: Commit fff985340fb652231dbac5b959386c0334ebfb11 in geode's branch refs/heads/feature/GEODE-8067 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fff9853 ] GEODE-8069: fix release script issues (#5050) fix versions and other issues encountered creating the support branches * clarify which new version to add to Jira * don't enable metrics by default, since they don't work * always create a starting build number for proper version cmp in concourse * do not use less as pager during release scripts, as it is confusing to need to press Q to continue * mention that prepare_rc can be re-run without commenting out completed steps, if desired * GEODE-8016: switch from -SNAPSHOT to -build.n * revise semantic version selector to use for geode-examples to find geode * ensure we are in correct dir for executing sub-scripts * dont fail if temp commit has already been reverted > Replace Maven SNAPSHOT with enumerated build-id artifacts > - > > Key: GEODE-8016 > URL: https://issues.apache.org/jira/browse/GEODE-8016 > Project: Geode > Issue Type: Task > Components: build, ci >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > To better support repeatable builds in CI, publish artifacts in the form > `1.2.3-build.123` instead of `1.2.3-SNAPSHOT` with the SNAPSHOT dynamically > changing. As an example, the `geode-examples` pipeline would be able to grab > a distinct artifact for build-and-test, instead of an unrepeatable, invisibly > rolling `SNAPSHOT`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110671#comment-17110671 ] ASF subversion and git services commented on GEODE-8037: Commit c6851bf73c208e39da54fe2f7ca80f35b8a61032 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6851bf ] GEODE-8037 - Create BootstrappingService interface. (#5046) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8130) Change the way redis uses geode regions to save memory and fix race conditions
[ https://issues.apache.org/jira/browse/GEODE-8130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110677#comment-17110677 ] ASF subversion and git services commented on GEODE-8130: Commit e084aa4bdaed4d626e559fec4e7e64e1fbf93755 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e084aa4 ] GEODE-8130: use a single region for redis Sets and Hashes (#5120) * Replaced replicated metaRegion with a partitioned dataRegion. Currently the dataRegion is used the same way as the metaRegion except for sets and hashes which store their actual data in it. * Exception handling now correctly deals with FunctionException * Disabled a test until GEODE-8127 if fixed. * Now uses the ByteArrayWrapper as the key on the meta region and the locks map instead of using a String. Since a ByteArrayWrapper is used as the key in the data region this will end up saving memory. * Found a problem with redis dynamic region management. Some of the code was executing when we added a new set or hash to the metaDataRegion. It was only ignoring STRING and HLL. This caused some extra memory to be used for every redis set/hash. Now the dynamic region code is only used for lists and sortedSet. * This commit has some TODO comments of what looks like a bug in the dynamic region code when a new server is started. It looks like the new server will not create already existing dynamic regions. We could test this by starting one server, create a LIST, then start another server, and then shutdown the first server. Does the LIST still exist? If we change them not to use dynamic regions then this issue will go away. > Change the way redis uses geode regions to save memory and fix race conditions > -- > > Key: GEODE-8130 > URL: https://issues.apache.org/jira/browse/GEODE-8130 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.14.0 > > > Currently the geode redis implementation uses a replicate region to hold > every redis key as the region key (as a String object) and the region value > is an enum describing the type. Another partitioned regioni is used to also > store the redis key as the region key (as a ByteArrayWrapper object) and the > region value is an object that is basically a Set or HashMap. > This uses extra memory, the replicate does not scale well, is slower > (updating two regions is slower than one region), and trying to update two > regions to hold the same logical redis "key" has race conditions which can > lead to inconsistent data. > The solution is to have a single partitioned region that can hold multiple > types of data (sets, hashes, strings, lists, etc). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8037) Create BootstrappingService Interface
[ https://issues.apache.org/jira/browse/GEODE-8037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110684#comment-17110684 ] ASF subversion and git services commented on GEODE-8037: Commit c6851bf73c208e39da54fe2f7ca80f35b8a61032 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6851bf ] GEODE-8037 - Create BootstrappingService interface. (#5046) > Create BootstrappingService Interface > - > > Key: GEODE-8037 > URL: https://issues.apache.org/jira/browse/GEODE-8037 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a BootstrapingService interface. The BootstrappingService will use the > ModuleService to bootstrap Geode in a classloader-isolated way, i.e. loading > the necessary modules to run Geode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8035) Parallel Disk Store Recovery when Cluster Restarts
[ https://issues.apache.org/jira/browse/GEODE-8035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110679#comment-17110679 ] ASF subversion and git services commented on GEODE-8035: Commit 0d602cc9d0b89cf875b883f53af912c2ddc4d26a in geode's branch refs/heads/feature/GEODE-8067 from Jianxia Chen [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d602cc ] GEODE-8035: Parallel Disk Store Recovery when Cluster Restarts (#5014) * Add parallel stream for disk store recovery * Replace synchronized block with CountDownLatch * Add the new system property parallelDiskStoreRecovery * Add documentation of the new system property Authored-by: Jianxia Chen > Parallel Disk Store Recovery when Cluster Restarts > -- > > Key: GEODE-8035 > URL: https://issues.apache.org/jira/browse/GEODE-8035 > Project: Geode > Issue Type: Improvement >Reporter: Jianxia Chen >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI > > Currently, when Geode cluster restarts, the disk store recovery is > serialized. When all regions share the same disk store, the restart process > is time consuming. To improve the performance, different regions can use > different disk stores with different disk controllers. And adding parallel > disk store recovery. This is expected to significantly reduce the time to > restart Geode cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8122) Update GeodeRedisServer java doc and Redis API for Geode documentation
[ https://issues.apache.org/jira/browse/GEODE-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110683#comment-17110683 ] ASF subversion and git services commented on GEODE-8122: Commit 4c12d70a14e2745d72bb2f11ed9c1687d128c892 in geode's branch refs/heads/feature/GEODE-8067 from Sarah Abbey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c12d70 ] GEODE-8122: Update Geode Redis API docs (#5122) Update the GeodeRedisServer java doc and the Redis API for Geode documentation. > Update GeodeRedisServer java doc and Redis API for Geode documentation > -- > > Key: GEODE-8122 > URL: https://issues.apache.org/jira/browse/GEODE-8122 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Sarah Abbey >Priority: Minor > > - Java doc for GeodeRedisServer updated for current GA release plans > - Java doc for ConfigurationProperties updated so it doesn't reference > internal GeodeRedisServer > - Geode docs for Redis API for Geode updated -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8069) release script fixes
[ https://issues.apache.org/jira/browse/GEODE-8069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110681#comment-17110681 ] ASF subversion and git services commented on GEODE-8069: Commit fff985340fb652231dbac5b959386c0334ebfb11 in geode's branch refs/heads/feature/GEODE-8067 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fff9853 ] GEODE-8069: fix release script issues (#5050) fix versions and other issues encountered creating the support branches * clarify which new version to add to Jira * don't enable metrics by default, since they don't work * always create a starting build number for proper version cmp in concourse * do not use less as pager during release scripts, as it is confusing to need to press Q to continue * mention that prepare_rc can be re-run without commenting out completed steps, if desired * GEODE-8016: switch from -SNAPSHOT to -build.n * revise semantic version selector to use for geode-examples to find geode * ensure we are in correct dir for executing sub-scripts * dont fail if temp commit has already been reverted > release script fixes > > > Key: GEODE-8069 > URL: https://issues.apache.org/jira/browse/GEODE-8069 > Project: Geode > Issue Type: Bug > Components: release >Reporter: Owen Nichols >Assignee: Owen Nichols >Priority: Major > > fix issues encountered in 1.14.0 release experience -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8127) redis function+delta may not always execute function on primary
[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110678#comment-17110678 ] ASF subversion and git services commented on GEODE-8127: Commit e084aa4bdaed4d626e559fec4e7e64e1fbf93755 in geode's branch refs/heads/feature/GEODE-8067 from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e084aa4 ] GEODE-8130: use a single region for redis Sets and Hashes (#5120) * Replaced replicated metaRegion with a partitioned dataRegion. Currently the dataRegion is used the same way as the metaRegion except for sets and hashes which store their actual data in it. * Exception handling now correctly deals with FunctionException * Disabled a test until GEODE-8127 if fixed. * Now uses the ByteArrayWrapper as the key on the meta region and the locks map instead of using a String. Since a ByteArrayWrapper is used as the key in the data region this will end up saving memory. * Found a problem with redis dynamic region management. Some of the code was executing when we added a new set or hash to the metaDataRegion. It was only ignoring STRING and HLL. This caused some extra memory to be used for every redis set/hash. Now the dynamic region code is only used for lists and sortedSet. * This commit has some TODO comments of what looks like a bug in the dynamic region code when a new server is started. It looks like the new server will not create already existing dynamic regions. We could test this by starting one server, create a LIST, then start another server, and then shutdown the first server. Does the LIST still exist? If we change them not to use dynamic regions then this issue will go away. > redis function+delta may not always execute function on primary > --- > > Key: GEODE-8127 > URL: https://issues.apache.org/jira/browse/GEODE-8127 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > The redis use of regions depends on the code that will modify the region that > is storing redis data, to always execute on the primary. It thought it was > accomplishing this by marking the function as "optimizeForWrite=true" and by > routing the function to the node with the bucket using "withFilter(key)". > This works most of the time. But in some cases the function executes on a > redundant copy. It looks like what is happening is that at the time the > function is dispatched it has one idea of who the primary is and sends the > function to that node. But before it executes the primary moves from this > node to another that is doing redundancy recovery. Then when our function > finally does a "put" on the localDataSet it ends up being a remote operation > that is sent to the other node. > If our redis function could get a lock that prevents the bucket primary > status from changing (see BucketRegion doLockForPrimary) and then check to > see if we are the primary (if not throw an exception that causes the function > sender to retry (see BucketMovedException) otherwise execute the function > and at the end release the lock (see BucketRegion doUnlockForPrimary). > We could enable this with a new method added to Function (much like the > existing isHA and optimizeForWrite). This new method could be > executeOnPrimary and default to false (adding a default method to the > Function interface will not cause backwards compatibility issues unless a > current class that implements Function already had added a method named > "executeOnPrimary"). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8094) Create HA test to ensure Spring Boot sessions expire correctly
[ https://issues.apache.org/jira/browse/GEODE-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110675#comment-17110675 ] ASF subversion and git services commented on GEODE-8094: Commit 4fff1f9fde1b1401c68722c015f65267bf5da971 in geode's branch refs/heads/feature/GEODE-8067 from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4fff1f9 ] GEODE-8094: Create HA test to ensure Spring Boot sessions expire correctly (#5079) Co-authored-by: Murtuza Boxwala Co-authored-by: Raymond Ingles Co-authored-by: Jens Deppe > Create HA test to ensure Spring Boot sessions expire correctly > -- > > Key: GEODE-8094 > URL: https://issues.apache.org/jira/browse/GEODE-8094 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Fix For: 1.14.0 > > > Write a high level test to ensure that sessions created by Spring Boot expire > correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8016) Replace Maven SNAPSHOT with enumerated build-id artifacts
[ https://issues.apache.org/jira/browse/GEODE-8016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110682#comment-17110682 ] ASF subversion and git services commented on GEODE-8016: Commit fff985340fb652231dbac5b959386c0334ebfb11 in geode's branch refs/heads/feature/GEODE-8067 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fff9853 ] GEODE-8069: fix release script issues (#5050) fix versions and other issues encountered creating the support branches * clarify which new version to add to Jira * don't enable metrics by default, since they don't work * always create a starting build number for proper version cmp in concourse * do not use less as pager during release scripts, as it is confusing to need to press Q to continue * mention that prepare_rc can be re-run without commenting out completed steps, if desired * GEODE-8016: switch from -SNAPSHOT to -build.n * revise semantic version selector to use for geode-examples to find geode * ensure we are in correct dir for executing sub-scripts * dont fail if temp commit has already been reverted > Replace Maven SNAPSHOT with enumerated build-id artifacts > - > > Key: GEODE-8016 > URL: https://issues.apache.org/jira/browse/GEODE-8016 > Project: Geode > Issue Type: Task > Components: build, ci >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.12.1, 1.13.0, 1.14.0 > > > To better support repeatable builds in CI, publish artifacts in the form > `1.2.3-build.123` instead of `1.2.3-SNAPSHOT` with the SNAPSHOT dynamically > changing. As an example, the `geode-examples` pipeline would be able to grab > a distinct artifact for build-and-test, instead of an unrepeatable, invisibly > rolling `SNAPSHOT`. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8078) Exceptions in locator logs when hitting members REST endpoint
[
https://issues.apache.org/jira/browse/GEODE-8078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110674#comment-17110674
]
ASF subversion and git services commented on GEODE-8078:
Commit a235c7c4ea2474d6fe347326ef888c7c10daffb6 in geode's branch
refs/heads/feature/GEODE-8067 from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a235c7c ]
GEODE-8078: log and report error at the correct place. (#5111)
* For get operation, if cache is not ready, just don't report any runtime
information
* do not log the CacheClosedException
> Exceptions in locator logs when hitting members REST endpoint
> -
>
> Key: GEODE-8078
> URL: https://issues.apache.org/jira/browse/GEODE-8078
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Priority: Major
> Labels: GeodeOperationAPI
>
> I'm seeing the following exceptions in locator logs when I try to hit the
> REST endpoint /management/v1/members/\{id} before the member has finished
> starting up. The reason I need to do this is because I have a program that is
> polling that endpoint to wait until the member is online. Ideally these
> errors would not show up in logs, but instead be reflected in the status code
> of the REST response.
> {quote}[error 2020/04/06 22:05:59.086 UTC tid=0x31] class
> org.apache.geode.cache.CacheClosedException cannot be cast to class
> org.apache.geode.management.runtime.RuntimeInfo
> (org.apache.geode.cache.CacheClosedException and
> org.apache.geode.management.runtime.RuntimeInfo are in unnamed module of
> loader 'app')
> java.lang.ClassCastException: class
> org.apache.geode.cache.CacheClosedException cannot be cast to class
> org.apache.geode.management.runtime.RuntimeInfo
> (org.apache.geode.cache.CacheClosedException and
> org.apache.geode.management.runtime.RuntimeInfo are in unnamed module of
> loader 'app')
> at
> org.apache.geode.management.internal.api.LocatorClusterManagementService.list(LocatorClusterManagementService.java:417)
> at
> org.apache.geode.management.internal.api.LocatorClusterManagementService.get(LocatorClusterManagementService.java:434)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController.getMember(MemberManagementController.java:50)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController$$FastClassBySpringCGLIB$$3634e452.invoke()
> at
> org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:769)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:747)
> at
> org.springframework.security.access.intercept.aopalliance.MethodSecurityInterceptor.invoke(MethodSecurityInterceptor.java:69)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:747)
> at
> org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:689)
> at
> org.apache.geode.management.internal.rest.controllers.MemberManagementController$$EnhancerBySpringCGLIB$$2893b195.getMember()
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:888)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:793)
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapt
[jira] [Commented] (GEODE-8096) redeployingParentClassDoesNotCauseSubclassIncompatibilities encounters ClassNotFoundException exception
[
https://issues.apache.org/jira/browse/GEODE-8096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110680#comment-17110680
]
ASF subversion and git services commented on GEODE-8096:
Commit 334e24fa559733b8824222f266e6df6cc5531f29 in geode's branch
refs/heads/feature/GEODE-8067 from Nabarun Nag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=334e24f ]
GEODE-8096: Providing unique names for the JARs in the tests (#5119)
* Same JAR names among tests in the same folder may be deleted by clean up from
previously run tests.
* Undeploying the JARs after test execution to remove the files from
the test environment so they don't run out of space.
> redeployingParentClassDoesNotCauseSubclassIncompatibilities encounters
> ClassNotFoundException exception
> ---
>
> Key: GEODE-8096
> URL: https://issues.apache.org/jira/browse/GEODE-8096
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: Bill Burcham
>Assignee: Nabarun Nag
>Priority: Major
> Labels: caching-applications
> Fix For: 1.14.0
>
>
> JUnit test failed in this CI run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/134#A
> {code}
> org.apache.geode.internal.ClassPathLoaderJUnitTest >
> redeployingParentClassDoesNotCauseSubclassIncompatibilities FAILED
> java.lang.ClassNotFoundException: jddunit.function.classB
> at
> org.apache.geode.internal.ClassPathLoader.forName(ClassPathLoader.java:186)
> at
> org.apache.geode.internal.ClassPathLoader$1.loadClass(ClassPathLoader.java:366)
> at
> org.apache.geode.internal.ClassPathLoaderJUnitTest.redeployingParentClassDoesNotCauseSubclassIncompatibilities(ClassPathLoaderJUnitTest.java:242)
> {code}
> I ran it 100 times in IntelliJ with no failures. On the theory that maybe we
> ran out of disk I visually traced through the paths dealing w/ (jar) files
> and didn't see anywhere where the product might have been swallowing
> exceptions. So I don't know what went wrong.
> Marked component as serialization because this is testing loading a Jar file
> that redefines a class which was the base class (of a derived class) loaded
> previously from a different jar file. Seems like the point of all that is
> mainly to support users updating their jar files without restarting their
> JVMs.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8133) Fix devBuild gradle target
[ https://issues.apache.org/jira/browse/GEODE-8133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110676#comment-17110676 ] ASF subversion and git services commented on GEODE-8133: Commit 32a01771f8bea9190f39aff30c85a93908a8342c in geode's branch refs/heads/feature/GEODE-8067 from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=32a0177 ] GEODE-8133: Fix task chaining for 'devBuild' (#5118) > Fix devBuild gradle target > -- > > Key: GEODE-8133 > URL: https://issues.apache.org/jira/browse/GEODE-8133 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Fix For: 1.14.0 > > > devBuild only runs spotlessApply instead of compilation tasks -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8041) Create ManagementService Interface
[ https://issues.apache.org/jira/browse/GEODE-8041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110685#comment-17110685 ] ASF subversion and git services commented on GEODE-8041: Commit bfad4a25b02fb3cf77bb52dbf614eb1d46cd0e41 in geode's branch refs/heads/feature/GEODE-8067 from Patrick Johnson [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bfad4a2 ] GEODE-8041 - Create ManagementService interface. (#5062) > Create ManagementService Interface > -- > > Key: GEODE-8041 > URL: https://issues.apache.org/jira/browse/GEODE-8041 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > > Create a ManagementService interface. The ManagementService will configure > and start Geode (create a Cache given some configuration properties) after > the BootstrappingService has bootstrapped the environment and loaded the > relevant modules. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8146) Restore winrm-cli to latest from source
Robert Houghton created GEODE-8146: -- Summary: Restore winrm-cli to latest from source Key: GEODE-8146 URL: https://issues.apache.org/jira/browse/GEODE-8146 Project: Geode Issue Type: Improvement Components: ci, tests Reporter: Robert Houghton winrm-cli has updated to fix the bug causing GEODE-7788, as reported in [their github|https://github.com/masterzen/winrm/issues/101] -- This message was sent by Atlassian Jira (v8.3.4#803005)
