[jira] [Created] (GEODE-9841) Move internal packages to conform to new internal package structure
Udo Kohlmeyer created GEODE-9841: Summary: Move internal packages to conform to new internal package structure Key: GEODE-9841 URL: https://issues.apache.org/jira/browse/GEODE-9841 Project: Geode Issue Type: Improvement Reporter: Udo Kohlmeyer Both ClassLoader and Deployment are in the `internal.classloader` and `internal.deployment` package structure, which would make more sense (and conform to newer thinking) to be `classloader.internal` and `deployment.internal`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9841) Move internal packages to conform to new internal package structure
[ https://issues.apache.org/jira/browse/GEODE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-9841: Assignee: Udo Kohlmeyer > Move internal packages to conform to new internal package structure > --- > > Key: GEODE-9841 > URL: https://issues.apache.org/jira/browse/GEODE-9841 > Project: Geode > Issue Type: Improvement >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > Both ClassLoader and Deployment are in the `internal.classloader` and > `internal.deployment` package structure, which would make more sense (and > conform to newer thinking) to be `classloader.internal` and > `deployment.internal`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460282#comment-17460282
]
Udo Kohlmeyer commented on GEODE-9857:
--
This seems to be a one time failure of this test. It seems the locator had not
stopped before the restarting of the locator was attempted. In future this
problem might be resolved by waiting for the locator to have stopped correctly
before trying to restart it.
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9857:
-
Labels: GeodeOperationAPI (was: GeodeOperationAPI needsTriage)
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460283#comment-17460283
]
Udo Kohlmeyer commented on GEODE-9857:
--
This test also has not failed since. Last available build is build 61 where
this test has not failed since the failure in build 24.
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-9974: Assignee: Udo Kohlmeyer > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > Labels: needsTriage > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.run
[jira] [Commented] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17480785#comment-17480785 ] Udo Kohlmeyer commented on GEODE-9974: -- Looking at this issue, is seems that there could have been an underlying infrastructural issue that occurred. Since the failed run 601, there have been no new failures since then (last run checked [800|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/800] > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > Labels: needsTriage > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at
[jira] [Resolved] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9974. -- Resolution: Cannot Reproduce > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(Parent
[jira] [Updated] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9974: - Labels: (was: needsTriage) > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRu
[jira] [Assigned] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-9995:
Assignee: Jens Deppe
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: backport, needsTriage, pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485014#comment-17485014
]
Udo Kohlmeyer commented on GEODE-9995:
--
assigning to [~jens.deppe], given the submitted PR.
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: backport, needsTriage, pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489918#comment-17489918
]
Udo Kohlmeyer commented on GEODE-10005:
---
[~jblum] currently Apache Geode has a baseline of JDK8, from we've not decided
to move from yet. Given that Jetty 10.x and 11.x has a baseline of JDK11, there
is no way for Apache Geode to use the newer Jetty version until we move the JDK
baseline to at least JDK 11+.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10038:
--
Labels: (was: needsTriage)
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
Udo Kohlmeyer created GEODE-10038:
-
Summary: Trying to access the QueryService results in NPE on
server restart from deployed Jar
Key: GEODE-10038
URL: https://issues.apache.org/jira/browse/GEODE-10038
Project: Geode
Issue Type: Bug
Components: functions
Affects Versions: 1.14.3, 1.13.7, 1.12.8, 1.15.0
Reporter: Udo Kohlmeyer
After deploying a jar which contains a Function, restarting the server causes
an NPE.
Using the Function definition of:
{code:java}
public class CustomFunction implements Function {
private GemFireCache cache;
private QueryService queryService;
public CustomFunction() {
this.cache = CacheFactory.getAnyInstance();
this.queryService = cache.getQueryService();
}
{code}
Due to the startup flow
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
the registration of Functions are initialized from cluster configuration
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
There is a dependency on the `QueryService` to be available at Function
construction time, but given that the services are only initialized
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
the call to the `cache.getQueryService` fails with an NPE
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Summary: Using JBoss Modules to implement classloader isolated jar deployment (was: Modify java.gradle to generate module.xml as well as the Manifest file) > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > In order to convert the current ClassLoader Isolation work to use `java -jar > jboss-modules` one would like to have `module.xml` files that standard > jboss-modules knows how to handle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Description: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. was: In order to convert the current ClassLoader Isolation work to use `java -jar jboss-modules` one would like to have `module.xml` files that standard jboss-modules knows how to handle. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491783#comment-17491783 ] Udo Kohlmeyer commented on GEODE-8705: -- The new ClassLoader isolation will be accomplished by using JBoss Modules. In order to make sure that the modular environment is correctly bootstrapped, it needs to be the first thing that is bootstrapped. To achieve this, the current approach to start the system, with all library dependencies declared on the root Classloader, will be replaced with the newer approach, which only has the jboss-modules library and a library which provides a custom ModuleLoader (a JBoss Modules construct) as the Boot Module loader for JBoss Modules. The new bootstrapping mechanism will also require a module.xml file to bootstrap the modules. In the current implementation there is one module.xml file that describes all the libraries, main class (entry class) and import/export restrictions of classes/packages. In order to avoid significant changes, the current approach (even if bootstrapped through org.jboss.modules.Main) takes the same command line parameters that one would pass to the Locator/Server Launcher. The Main class from JBoss modules just acts as a pass through and passes through all parameters to the main classes defined in the module.xml file. (in this case ServerLauncher). There is a current project structure for deployment: * geode-deployment-acceptence (Acceptence tests to ensure that no functionality is broken between the two classloader mechanisms) * geode-deployment-jboss-modules - JBoss modules classloader implementation * geode-deployment-chained-classloader - Previous classloader implementation * geode-deployment-test - Test project to create a Spring project that uses conflicting libraries to main project * geode-jboss-extensions - Project to provide extensions to the JBoss Modules framework, that needs to be on the root Classloader. In order to minimize the module.xml maintenance, a Gradle Plugin has been written to generate the module.xml file from the gradle dependencies. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491784#comment-17491784 ] Udo Kohlmeyer commented on GEODE-8705: -- Modified DUnit testing framework to be able to run either Classloader isolated or the default classloader mechanism. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491786#comment-17491786 ] Udo Kohlmeyer commented on GEODE-8705: -- Completed work to complete testing in Hydra in a classloader isolated manner.. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[
https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17491783#comment-17491783
]
Udo Kohlmeyer edited comment on GEODE-8705 at 2/14/22, 4:10 AM:
The new ClassLoader isolation will be accomplished by using JBoss Modules. In
order to make sure that the modular environment is correctly bootstrapped, it
needs to be the first thing that is bootstrapped. To achieve this, the current
approach to start the system, with all library dependencies declared on the
root Classloader, will be replaced with the newer approach, which only has the
jboss-modules library and a library which provides a custom ModuleLoader (a
JBoss Modules construct) as the Boot Module loader for JBoss Modules.
The new bootstrapping mechanism will also require a module.xml file to
bootstrap the modules. In the current implementation there is one module.xml
file that describes all the libraries, main class (entry class) and
import/export restrictions of classes/packages.
In order to avoid significant changes, the current approach (even if
bootstrapped through org.jboss.modules.Main) takes the same command line
parameters that one would pass to the Locator/Server Launcher. The Main class
from JBoss modules just acts as a pass through and passes through all
parameters to the main classes defined in the module.xml file. (in this case
ServerLauncher).
There is a current project structure for deployment:
* geode-deployment-acceptence (Acceptence tests to ensure that no
functionality is broken between the two classloader mechanisms)
* geode-deployment-jboss-modules - JBoss modules classloader implementation
* geode-deployment-chained-classloader - Previous classloader implementation
* geode-deployment-test - Test project to create a Spring project that uses
conflicting libraries to main project
* geode-jboss-extensions - Project to provide extensions to the JBoss Modules
framework, that needs to be on the root Classloader.
In order to minimize the module.xml maintenance, a Gradle Plugin has been
written to generate the module.xml file from the gradle dependencies.
Also, to limit the initial scope of the Classloader isolation, Classloader
isolation will only be available if you start a Locator or Server when they are
started through {_}gfsh{_}. Using the "{_}--enable-classloader-isolation{_}"
flag will start the component as either classloader isolated or default
classloader mechanism.
was (Author: ukohlmeyer):
The new ClassLoader isolation will be accomplished by using JBoss Modules. In
order to make sure that the modular environment is correctly bootstrapped, it
needs to be the first thing that is bootstrapped. To achieve this, the current
approach to start the system, with all library dependencies declared on the
root Classloader, will be replaced with the newer approach, which only has the
jboss-modules library and a library which provides a custom ModuleLoader (a
JBoss Modules construct) as the Boot Module loader for JBoss Modules.
The new bootstrapping mechanism will also require a module.xml file to
bootstrap the modules. In the current implementation there is one module.xml
file that describes all the libraries, main class (entry class) and
import/export restrictions of classes/packages.
In order to avoid significant changes, the current approach (even if
bootstrapped through org.jboss.modules.Main) takes the same command line
parameters that one would pass to the Locator/Server Launcher. The Main class
from JBoss modules just acts as a pass through and passes through all
parameters to the main classes defined in the module.xml file. (in this case
ServerLauncher).
There is a current project structure for deployment:
* geode-deployment-acceptence (Acceptence tests to ensure that no
functionality is broken between the two classloader mechanisms)
* geode-deployment-jboss-modules - JBoss modules classloader implementation
* geode-deployment-chained-classloader - Previous classloader implementation
* geode-deployment-test - Test project to create a Spring project that uses
conflicting libraries to main project
* geode-jboss-extensions - Project to provide extensions to the JBoss Modules
framework, that needs to be on the root Classloader.
In order to minimize the module.xml maintenance, a Gradle Plugin has been
written to generate the module.xml file from the gradle dependencies.
> Using JBoss Modules to implement classloader isolated jar deployment
>
>
> Key: GEODE-8705
> URL: https://issues.apache.org/jira/browse/GEODE-8705
> Project: Geode
> Issue Type: New Feature
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-availab
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Description: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. See RFC [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for further details was: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. > > See RFC > [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for > further details -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9984) Mass-Test-Run: WanCopyRegionCommandDUnitTest > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED
[ https://issues.apache.org/jira/browse/GEODE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9984: - Labels: flaky-test pull-request-available (was: needsTriage pull-request-available) > Mass-Test-Run: WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED > - > > Key: GEODE-9984 > URL: https://issues.apache.org/jira/browse/GEODE-9984 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Alberto Gomez >Priority: Major > Labels: flaky-test, pull-request-available > > WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(true, true) [0] FAILED > org.opentest4j.AssertionFailedError: > expected: 5 > but was: 50001 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(WanCopyRegionCommandDUnitTest.java:884) > 948 tests completed, 1 failed, 59 skipped > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642850654/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz*] > > > > May be an issue similar or related to > https://issues.apache.org/jira/browse/GEODE-9859. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9859) Mass-Test-Run: WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false, false) [0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9859:
-
Labels: pull-request-available (was: needsTriage pull-request-available)
> Mass-Test-Run:
> WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
>
>
> Key: GEODE-9859
> URL: https://issues.apache.org/jira/browse/GEODE-9859
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Looks like this might be failing from the original PR. I have linked to
> GEODE-9369 as the most likely origination.
>
> {noformat}
> WanCopyRegionCommandDUnitTest > testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
> java.lang.AssertionError:
> Expecting elements:
> ["Execution failed. Error:
> org.apache.geode.cache.EntryDestroyedException: 937"]
> to have exactly 1 times execution error
> at
> org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(WanCopyRegionCommandDUnitTest.java:450)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10067) WANCopyRegionFunctionDelegate needs to be optimized to handle large regions
Udo Kohlmeyer created GEODE-10067: - Summary: WANCopyRegionFunctionDelegate needs to be optimized to handle large regions Key: GEODE-10067 URL: https://issues.apache.org/jira/browse/GEODE-10067 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current WanCopyRegionFunctionDelegate may cause significant memory issues in with really large regions. The [getEntries|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L102] method returns both primary and redundant Region Entries for local server. The invocation of getEntries from the PartitionedRegionDataStore will cause all entries to be deserialized https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java#L2501-L2515 The [createBatch|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L107-L108] method creates a List equally that of the local Region size. Essentially ... In a system with VERY large regions this might cause significant memory issues -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10068) Make WanCopyRegionFunctionService thread pool configurable through configuration or property
Udo Kohlmeyer created GEODE-10068: - Summary: Make WanCopyRegionFunctionService thread pool configurable through configuration or property Key: GEODE-10068 URL: https://issues.apache.org/jira/browse/GEODE-10068 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current implementation of `WanCopyRegionFunctionService` creates a fixed thread pool of size 10. This is possibly something that one would like to be able to configure. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10069) WanCopyRegionCommand currently targets all members in cluster
Udo Kohlmeyer created GEODE-10069: - Summary: WanCopyRegionCommand currently targets all members in cluster Key: GEODE-10069 URL: https://issues.apache.org/jira/browse/GEODE-10069 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current implementation of `WanCopyRegionCommand` will execute on all members. This could possibly be improved by targeting a single member, which then has the ability to determine if the wan copy functionality needs to run on a single member (in the case of Replicate regions) or across multiple members (in the case of Partitioned Regions). In addition, initiating function also has the ability to invoke the function using `onRegion` which then allows for the targeting of primary data only vs the current implementation which (perceivably) targets primary and redundant bucket data -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10070) Add method onto InternalGatewaySender to send batch
Udo Kohlmeyer created GEODE-10070: - Summary: Add method onto InternalGatewaySender to send batch Key: GEODE-10070 URL: https://issues.apache.org/jira/browse/GEODE-10070 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer In the current Wan Copy feature, the `WanCopyRegionFunctionDelegate` has to: # Create a ConnectionState # retrieve the GatewaySenderEventDispatcher off the AbstractGatewaySender # Send batch and handle all exception handling related to the sending of a batch This functionality is really something that needs to be consolidated into a single location for reuse. Having the ability to get into guts of the system to send batches and possibly affect how errors are handled in an inconsistent manner (in comparison to the normal GatewaySender flow) can lead to many problems. Not exposing the sendBatch logic and complexity would be much simpler and more consistent in behavior. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
Udo Kohlmeyer created GEODE-10071: - Summary: Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand Key: GEODE-10071 URL: https://issues.apache.org/jira/browse/GEODE-10071 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer There is a cyclical dependency between the Command and the implementing function for the Wan copy feature. Logically, the command needs to have a dependency on the function. The error messages currently defined in the Command class need to be moved to the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9393:
-
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16, Java17
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - 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:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.Buf
[jira] [Updated] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9393:
-
Labels: Java16 Java17 (was: Java16)
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16, Java17
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - 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:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(Buf
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10036:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Bug)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
[
https://issues.apache.org/jira/browse/GEODE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9657:
-
Parent: GEODE-10003
Issue Type: Sub-task (was: Bug)
> Javadoc errors occur on Java 17 due to split packages in Geode
> --
>
> Key: GEODE-9657
> URL: https://issues.apache.org/jira/browse/GEODE-9657
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.13.4, 1.14.0
>Reporter: John Blum
>Priority: Major
>
> When trying to build any library, framework (e.g. _Spring Data for Apache
> Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors
> occur.
> For example:
> {code}
> 22:36:52 [ERROR]
> /opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
> error: cannot access Identifiable
> 22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
> 22:36:52 [ERROR]^
> 22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not
> found
> {code}
> As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
> _Javadoc_ is started with:
> {code}
> javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
> {code}
> {{geode-core-1.14.0.jar}} ships
> {{org.apache.geode.lang.AttachAPINotFoundException}} and
> {{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
> to this split-package arrangement, _Javadoc_ isn’t discovering
> {{Identifiable}} because it has found the package {{org.apache.geode.lang}}
> in {{geode-core-1.14.0.jar}}.
> The best course of action is to make sure all {{org.apache.geode.lang}}
> sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other
> (i.e. {{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10007:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
> Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer
> REST API) when external hosting is not an option. Of course, these Web apps
> need to be updated as well (to use the new Jakarta EE 9 specs).
> There are other examples of SPIs used in Apache Geode, which are part of the
> non-internal, public API.
> For example, the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
> interface, with 1 such
> [implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
> provided by _Spring Data for Apache Geode_ (SDG) even.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Parent: (was: GEODE-10003)
Issue Type: Bug (was: Sub-task)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer, blocks-1.15.0
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10159) Upgrade to Micrometer 1.9
Udo Kohlmeyer created GEODE-10159: - Summary: Upgrade to Micrometer 1.9 Key: GEODE-10159 URL: https://issues.apache.org/jira/browse/GEODE-10159 Project: Geode Issue Type: Sub-task Components: statistics Reporter: Udo Kohlmeyer Micrometer 2.x introduces a new set of issues: * Not being released in time for 9.15 * Package name restructuring * External public API's directly exposing the Micrometer classes, need to be updated, and in so any external projects depending the exposed API In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, Micrometer is releasing 1.9 version that will be the bridge between 1.x and 2.x. Spring Data Geode has already tested that updating to this version resolves the issues that it has when integrating with Spring Boot 3.0, and deems this version to be good. Micrometer 1.9 has not made GA yet, but it is expected to be released around May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Labels: Micrometer (was: Micrometer blocks-1.15.0)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Issue Type: Improvement (was: Bug)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17511525#comment-17511525
]
Udo Kohlmeyer commented on GEODE-10045:
---
relates to https://issues.apache.org/jira/browse/GEODE-10159
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache
[ https://issues.apache.org/jira/browse/GEODE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4679: Assignee: Udo Kohlmeyer > pdxReadSerialized accessors must be present in some product level component > like Cache > -- > > Key: GEODE-4679 > URL: https://issues.apache.org/jira/browse/GEODE-4679 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > +*Current situation:*+ > The getters/setters for pdxReadSerialized thread is present in DefaultQuery > as static calls. > * DefaultQuery # getPdxReadSerialized() > * DefaultQuery # setPdxReadSerialized() > > +*Solution:*+ > These getters/setters need to move to a more logical part of the code like > cache and not be present in DeafaultQuery > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache
[ https://issues.apache.org/jira/browse/GEODE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4679: Assignee: (was: Udo Kohlmeyer) > pdxReadSerialized accessors must be present in some product level component > like Cache > -- > > Key: GEODE-4679 > URL: https://issues.apache.org/jira/browse/GEODE-4679 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: nabarun >Priority: Major > > +*Current situation:*+ > The getters/setters for pdxReadSerialized thread is present in DefaultQuery > as static calls. > * DefaultQuery # getPdxReadSerialized() > * DefaultQuery # setPdxReadSerialized() > > +*Solution:*+ > These getters/setters need to move to a more logical part of the code like > cache and not be present in DeafaultQuery > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4685: Assignee: Udo Kohlmeyer > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache
[ https://issues.apache.org/jira/browse/GEODE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4679: Assignee: Udo Kohlmeyer > pdxReadSerialized accessors must be present in some product level component > like Cache > -- > > Key: GEODE-4679 > URL: https://issues.apache.org/jira/browse/GEODE-4679 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > +*Current situation:*+ > The getters/setters for pdxReadSerialized thread is present in DefaultQuery > as static calls. > * DefaultQuery # getPdxReadSerialized() > * DefaultQuery # setPdxReadSerialized() > > +*Solution:*+ > These getters/setters need to move to a more logical part of the code like > cache and not be present in DeafaultQuery > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
Udo Kohlmeyer created GEODE-4791: Summary: Increase gradle version from 3.5.1 to 4.51 Key: GEODE-4791 URL: https://issues.apache.org/jira/browse/GEODE-4791 Project: Geode Issue Type: Improvement Components: build, general Reporter: Udo Kohlmeyer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4791: Assignee: Udo Kohlmeyer > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4791. -- Resolution: Fixed Fix Version/s: 1.6.0 > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3926) Lucene Query should throw an exception while lucene index is being built on existing region
[ https://issues.apache.org/jira/browse/GEODE-3926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-3926: Assignee: Udo Kohlmeyer > Lucene Query should throw an exception while lucene index is being built on > existing region > --- > > Key: GEODE-3926 > URL: https://issues.apache.org/jira/browse/GEODE-3926 > Project: Geode > Issue Type: Sub-task > Components: lucene >Reporter: Jason Huynh >Assignee: Udo Kohlmeyer >Priority: Major > > When GEODE-3928 is complete, we will have a process to index existing data in > a region when a lucene index is added. That process may take some time. While > indexing is going on queries should not block for a long period of time or > return incorrect results. Instead the query should throw an exception > indicating that the index does not exist/is not built yet. > Acceptance: > Queries executed while indexing is going on throw an exception, rather than > blocking or returning incorrect results. > Implementation Details: > GEODE-3928 is about modifying computeRepository to actually do the indexing. > Queries also call compute repository, so they will block until > computeRepository is done. > To avoid blocking, we can make computeRepo to return an IndexRepository in > an "building" state. That index repo could contain an asynchronous task that > is actually indexing the data. Until the asynchronous task is complete, the > IndexRepostory could throw exceptions from query operations. This has the > advantage of making sure that whenever computeRepository is called, we always > at least start or make sure there is a task running to index the data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4679) pdxReadSerialized accessors must be present in some product level component like Cache
[ https://issues.apache.org/jira/browse/GEODE-4679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4679. -- Resolution: Fixed Fix Version/s: 1.6.0 > pdxReadSerialized accessors must be present in some product level component > like Cache > -- > > Key: GEODE-4679 > URL: https://issues.apache.org/jira/browse/GEODE-4679 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.6.0 > > > +*Current situation:*+ > The getters/setters for pdxReadSerialized thread is present in DefaultQuery > as static calls. > * DefaultQuery # getPdxReadSerialized() > * DefaultQuery # setPdxReadSerialized() > > +*Solution:*+ > These getters/setters need to move to a more logical part of the code like > cache and not be present in DeafaultQuery > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4685. -- Resolution: Fixed Fix Version/s: 1.6.0 > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 5h 20m > Remaining Estimate: 0h > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4683) Replace setPdxReadSerialized in org.apache.geode.distributed.internal.streaming;
[ https://issues.apache.org/jira/browse/GEODE-4683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4683. -- Resolution: Fixed Assignee: Udo Kohlmeyer Fix Version/s: 1.6.0 > Replace setPdxReadSerialized in > org.apache.geode.distributed.internal.streaming; > > > Key: GEODE-4683 > URL: https://issues.apache.org/jira/browse/GEODE-4683 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.6.0 > > > Replace with the fix available from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4684) Replace setPdxReadSerialized and getPdxReadSerialized in org.apache.geode.internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4684. -- Resolution: Fixed Assignee: Udo Kohlmeyer Fix Version/s: 1.6.0 > Replace setPdxReadSerialized and getPdxReadSerialized in > org.apache.geode.internal.cache > > > Key: GEODE-4684 > URL: https://issues.apache.org/jira/browse/GEODE-4684 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.6.0 > > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4682) Remove setPdxReadSerialized and getPdxReadSerialized from org.apache.geode.cache.query.internal.index
[ https://issues.apache.org/jira/browse/GEODE-4682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4682. -- Resolution: Fixed Assignee: Udo Kohlmeyer Fix Version/s: 1.6.0 > Remove setPdxReadSerialized and getPdxReadSerialized from > org.apache.geode.cache.query.internal.index > -- > > Key: GEODE-4682 > URL: https://issues.apache.org/jira/browse/GEODE-4682 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.6.0 > > > The solution / outcome of GEODE-4682 must be used as the replacement for > org.apache.geode.cache.query.internal.index -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4681) Remove all static methods involving pdxReadSerialized
[ https://issues.apache.org/jira/browse/GEODE-4681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-4681. -- Resolution: Fixed Assignee: Udo Kohlmeyer Fix Version/s: 1.6.0 > Remove all static methods involving pdxReadSerialized > -- > > Key: GEODE-4681 > URL: https://issues.apache.org/jira/browse/GEODE-4681 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.6.0 > > > Remove the following static methods after GEODE-4679 is completed. > * setPdxReadSerialized() > * getPdxReadSerialized() -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-4791: - Fix Version/s: (was: 1.6.0) > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-4791) Increase gradle version from 3.5.1 to 4.51
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reopened GEODE-4791: -- > Increase gradle version from 3.5.1 to 4.51 > -- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4926) ClientServerMiscBCDUnitTest > testSubscriptionWithMixedServersAndOldPeerFeed failed
Udo Kohlmeyer created GEODE-4926:
Summary: ClientServerMiscBCDUnitTest >
testSubscriptionWithMixedServersAndOldPeerFeed failed
Key: GEODE-4926
URL: https://issues.apache.org/jira/browse/GEODE-4926
Project: Geode
Issue Type: Bug
Components: ci, client/server
Reporter: Udo Kohlmeyer
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/220
{code:java}
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest >
testSubscriptionWithMixedServersAndOldPeerFeed[1] FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
d7d1dbe8d1e3 with 5 VMs with version 120
at org.apache.geode.test.dunit.VM.invoke(VM.java:401)
at org.apache.geode.test.dunit.VM.invoke(VM.java:370)
at org.apache.geode.test.dunit.VM.invoke(VM.java:301)
at
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.doTestSubscriptionWithMixedServersAndPeerFeed(ClientServerMiscBCDUnitTest.java:214)
at
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.testSubscriptionWithMixedServersAndOldPeerFeed(ClientServerMiscBCDUnitTest.java:127)
Caused by:
java.lang.AssertionError: expected:<4> but was:<3>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at
org.apache.geode.internal.cache.tier.sockets.ClientServerMiscBCDUnitTest.lambda$doTestSubscriptionWithMixedServersAndPeerFeed$60ce2e92$8(ClientServerMiscBCDUnitTest.java:222)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4948) CI Failure: org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest testDLockProtectsAgainstTransactionConflict
Udo Kohlmeyer created GEODE-4948:
Summary: CI Failure:
org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest
testDLockProtectsAgainstTransactionConflict
Key: GEODE-4948
URL: https://issues.apache.org/jira/browse/GEODE-4948
Project: Geode
Issue Type: Bug
Components: distributed lock service
Reporter: Udo Kohlmeyer
{noformat}
Started @ 2018-03-24 05:00:58.670 +
Ended @ 2018-03-24 05:03:18.615 +
Started @ 2018-03-24 05:03:42.413 +
2018-03-24 05:31:23.431 +
org.apache.geode.distributed.internal.DlockAndTxlockRegressionTest
testDLockProtectsAgainstTransactionConflict
Ended @ 2018-03-24 07:22:12.143 +
Started @ 2018-03-24 04:12:27.592 +
Ended @ 2018-03-24 05:00:51.346 +
Started @ 2018-03-24 04:10:29.782 +
Ended @ 2018-03-24 04:11:58.704 +000{noformat}
>From the Stack dumps it seems to be waiting for the DLock:
{noformat}
"Pooled Waiting Message Processor 0" #123 daemon prio=5 os_prio=0
tid=0x7f1534032800 nid=0x294 in Object.wait() [0x7f15cd5e]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at
org.apache.geode.internal.cache.locks.TXLessorDepartureHandler.waitForInProcessDepartures(TXLessorDepartureHandler.java:46)
- locked <0xe0675468> (a java.lang.Object)
at
org.apache.geode.distributed.internal.locks.DLockGrantor.handleLockBatch(DLockGrantor.java:489)
- locked <0xe07118b8> (a java.util.HashMap)
at
org.apache.geode.distributed.internal.locks.DLockGrantor.handleLockRequest(DLockGrantor.java:749)
at
org.apache.geode.distributed.internal.locks.DLockRequestProcessor$DLockRequestMessage.basicProcess(DLockRequestProcessor.java:695)
at
org.apache.geode.distributed.internal.locks.DLockRequestProcessor$DLockRequestMessage$1.run(DLockRequestProcessor.java:597)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run(ClusterDistributionManager.java:863)
at java.lang.Thread.run(Thread.java:748)
{noformat}
is causing the Processor 1 to wait
{noformat}
"Pooled Waiting Message Processor 1" #172 daemon prio=5 os_prio=0
tid=0x7f153404a000 nid=0x2e1 waiting for monitor entry [0x7f1527bfa000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.geode.distributed.internal.locks.DLockGrantor.releaseLockBatch(DLockGrantor.java:662)
- waiting to lock <0xe07118b8> (a java.util.HashMap)
at
org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor.sendMessage(TXOriginatorRecoveryProcessor.java:91)
at
org.apache.geode.internal.cache.locks.TXLessorDepartureHandler$1.run(TXLessorDepartureHandler.java:97)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1118)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run(ClusterDistributionManager.java:863)
at java.lang.Thread.run(Thread.java:748){noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5096) AddCacheServerProfile should throw an error when conflicting Lucene are concurrently created
Udo Kohlmeyer created GEODE-5096: Summary: AddCacheServerProfile should throw an error when conflicting Lucene are concurrently created Key: GEODE-5096 URL: https://issues.apache.org/jira/browse/GEODE-5096 Project: Geode Issue Type: New Feature Components: lucene Reporter: Udo Kohlmeyer When two servers concurrently define a LuceneIndex, the addCacheServerProfile should throw an error to avoid conflicting indexes being defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5096) AddCacheServerProfile should throw an error when conflicting Lucene indexes are concurrently created
[ https://issues.apache.org/jira/browse/GEODE-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-5096: - Summary: AddCacheServerProfile should throw an error when conflicting Lucene indexes are concurrently created (was: AddCacheServerProfile should throw an error when conflicting Lucene are concurrently created) > AddCacheServerProfile should throw an error when conflicting Lucene indexes > are concurrently created > > > Key: GEODE-5096 > URL: https://issues.apache.org/jira/browse/GEODE-5096 > Project: Geode > Issue Type: New Feature > Components: lucene >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > When two servers concurrently define a LuceneIndex, the addCacheServerProfile > should throw an error to avoid conflicting indexes being defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5096) AddCacheServerProfile should throw an error when conflicting Lucene are concurrently created
[ https://issues.apache.org/jira/browse/GEODE-5096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-5096: Assignee: Udo Kohlmeyer > AddCacheServerProfile should throw an error when conflicting Lucene are > concurrently created > > > Key: GEODE-5096 > URL: https://issues.apache.org/jira/browse/GEODE-5096 > Project: Geode > Issue Type: New Feature > Components: lucene >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > When two servers concurrently define a LuceneIndex, the addCacheServerProfile > should throw an error to avoid conflicting indexes being defined. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-925) CI failure: QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch
[
https://issues.apache.org/jira/browse/GEODE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-925:
---
Assignee: Udo Kohlmeyer
> CI failure:
> QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch
> -
>
> Key: GEODE-925
> URL: https://issues.apache.org/jira/browse/GEODE-925
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Sai Boorlagadda
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: CI, Flaky
>
> {noformat}
> Error Message
> junit.framework.AssertionFailedError: Thread did not terminate after 200 ms:
> Thread[run invoked on an instance of
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest$9,5,]
> Stacktrace
> junit.framework.AssertionFailedError: Thread did not terminate after 200 ms:
> Thread[run invoked on an instance of
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest$9,5,]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> com.gemstone.gemfire.test.dunit.DistributedTestCase.join(DistributedTestCase.java:1241)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch(QueryDataInconsistencyDUnitTest.java:386)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5129) Amend DistributedTestRule to honor the vmCount paramter < 4
Udo Kohlmeyer created GEODE-5129: Summary: Amend DistributedTestRule to honor the vmCount paramter < 4 Key: GEODE-5129 URL: https://issues.apache.org/jira/browse/GEODE-5129 Project: Geode Issue Type: Improvement Components: tests Reporter: Udo Kohlmeyer -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5129) Amend DistributedTestRule to honor the vmCount paramter < 4
[ https://issues.apache.org/jira/browse/GEODE-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-5129: Assignee: Udo Kohlmeyer > Amend DistributedTestRule to honor the vmCount paramter < 4 > --- > > Key: GEODE-5129 > URL: https://issues.apache.org/jira/browse/GEODE-5129 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
Udo Kohlmeyer created GEODE-7241: Summary: Artifacts for geode-web and geode-web-api are jars instead of wars in maven central Key: GEODE-7241 URL: https://issues.apache.org/jira/browse/GEODE-7241 Project: Geode Issue Type: Bug Components: build Reporter: Udo Kohlmeyer Fix For: 1.11.0 In maven central the artifact for `geode-web` and `geode-web-api` are jars instead of the expected wars. This seems to be problem with the build/publish script that seems to have changed in 1.8. As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7241: Assignee: Robert Houghton > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Affects Version/s: 1.8.0 1.9.0 1.9.1 > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1 >Reporter: Udo Kohlmeyer >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Fix Version/s: (was: 1.11.0) > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Affects Version/s: 1.10.0 > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > Fix For: 1.11.0 > > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central
[ https://issues.apache.org/jira/browse/GEODE-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7241: - Description: In maven central the artifact for `geode-web` and `geode-web-api` are jars instead of the expected wars. This seems to be problem with the build/publish script that seems to have changed in 1.8. As this problem started in 1.8 This has become a problem when running the Spring Data Geode examples and tests. The functionality that is now impeded, is the ability to start a Server with HTTP enabled using only maven/gradle dependency management. The functionality to enable this was enabled by GEODE-5660, the ability to find the `geode-web` and `geode-web-api` artifacts on the classpath. Removing this ability will hinder users to effectively run any GEODE integration tests which might want to use the REST interfaces. Making sure that the correct version of the Geode project is installed in order to start a server(s) is a little cumbersome. was: In maven central the artifact for `geode-web` and `geode-web-api` are jars instead of the expected wars. This seems to be problem with the build/publish script that seems to have changed in 1.8. As this problem started in 1.8 > Artifacts for geode-web and geode-web-api are jars instead of wars in maven > central > --- > > Key: GEODE-7241 > URL: https://issues.apache.org/jira/browse/GEODE-7241 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > In maven central the artifact for `geode-web` and `geode-web-api` are jars > instead of the expected wars. > This seems to be problem with the build/publish script that seems to have > changed in 1.8. > As this problem started in 1.8 > This has become a problem when running the Spring Data Geode examples and > tests. The functionality that is now impeded, is the ability to start a > Server with HTTP enabled using only maven/gradle dependency management. The > functionality to enable this was enabled by GEODE-5660, the ability to find > the `geode-web` and `geode-web-api` artifacts on the classpath. > Removing this ability will hinder users to effectively run any GEODE > integration tests which might want to use the REST interfaces. Making sure > that the correct version of the Geode project is installed in order to start > a server(s) is a little cumbersome. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7412) Artifacts for geode-pulse is a jars instead of war in maven central
[ https://issues.apache.org/jira/browse/GEODE-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7412: - Component/s: build > Artifacts for geode-pulse is a jars instead of war in maven central > --- > > Key: GEODE-7412 > URL: https://issues.apache.org/jira/browse/GEODE-7412 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0, 1.9.2 >Reporter: Udo Kohlmeyer >Priority: Major > > Artifacts for geode-pulse is a jar instead of a war in maven central -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7412) Artifacts for geode-pulse is a jars instead of war in maven central
Udo Kohlmeyer created GEODE-7412: Summary: Artifacts for geode-pulse is a jars instead of war in maven central Key: GEODE-7412 URL: https://issues.apache.org/jira/browse/GEODE-7412 Project: Geode Issue Type: Bug Reporter: Udo Kohlmeyer Artifacts for geode-pulse is a jar instead of a war in maven central -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7412) Artifacts for geode-pulse is a jars instead of war in maven central
[ https://issues.apache.org/jira/browse/GEODE-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7412: - Affects Version/s: 1.8.0 1.9.0 1.9.1 1.10.0 1.9.2 > Artifacts for geode-pulse is a jars instead of war in maven central > --- > > Key: GEODE-7412 > URL: https://issues.apache.org/jira/browse/GEODE-7412 > Project: Geode > Issue Type: Bug >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0, 1.9.2 >Reporter: Udo Kohlmeyer >Priority: Major > > Artifacts for geode-pulse is a jar instead of a war in maven central -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7412) Artifacts for geode-pulse is a jars instead of war in maven central
[ https://issues.apache.org/jira/browse/GEODE-7412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7412: Assignee: Robert Houghton > Artifacts for geode-pulse is a jars instead of war in maven central > --- > > Key: GEODE-7412 > URL: https://issues.apache.org/jira/browse/GEODE-7412 > Project: Geode > Issue Type: Bug > Components: build >Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0, 1.9.2 >Reporter: Udo Kohlmeyer >Assignee: Robert Houghton >Priority: Major > > Artifacts for geode-pulse is a jar instead of a war in maven central -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7587) Incorrect dependency direction between geode-core and geode-management
Udo Kohlmeyer created GEODE-7587: Summary: Incorrect dependency direction between geode-core and geode-management Key: GEODE-7587 URL: https://issues.apache.org/jira/browse/GEODE-7587 Project: Geode Issue Type: Bug Components: management Reporter: Udo Kohlmeyer The current module dependency tree is inverted. Geode-core has a strong dependency on geode-management. Which is causing geode-managment's dependency on Spring to be leaked into geode-core. This dependency needs to be inverted where geode-management has a dependency on geode-core. That way there is no leaking of Spring dependencies into geode-core. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7587) Incorrect dependency direction between geode-core and geode-management
[ https://issues.apache.org/jira/browse/GEODE-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7587: Assignee: Jinmei Liao > Incorrect dependency direction between geode-core and geode-management > -- > > Key: GEODE-7587 > URL: https://issues.apache.org/jira/browse/GEODE-7587 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Udo Kohlmeyer >Assignee: Jinmei Liao >Priority: Major > > The current module dependency tree is inverted. Geode-core has a strong > dependency on geode-management. Which is causing geode-managment's dependency > on Spring to be leaked into geode-core. > This dependency needs to be inverted where geode-management has a dependency > on geode-core. That way there is no leaking of Spring dependencies into > geode-core. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7587) Incorrect dependency direction between geode-core and geode-management
[ https://issues.apache.org/jira/browse/GEODE-7587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7587: - Affects Version/s: 1.11.0 1.10.0 > Incorrect dependency direction between geode-core and geode-management > -- > > Key: GEODE-7587 > URL: https://issues.apache.org/jira/browse/GEODE-7587 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.10.0, 1.11.0 >Reporter: Udo Kohlmeyer >Assignee: Jinmei Liao >Priority: Major > > The current module dependency tree is inverted. Geode-core has a strong > dependency on geode-management. Which is causing geode-managment's dependency > on Spring to be leaked into geode-core. > This dependency needs to be inverted where geode-management has a dependency > on geode-core. That way there is no leaking of Spring dependencies into > geode-core. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7159: Assignee: Udo Kohlmeyer > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls
[
https://issues.apache.org/jira/browse/GEODE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-7531:
Assignee: Udo Kohlmeyer
> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> A recent
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
> to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all
> {{o.a.g.cache.client.Pools}} registered with the
> {{o.a.g.cache.client.PoolManager}} to be
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly
> "mock" 1 or more {{Pool}} instances and additionally needs to register the
> mock {{Pool}} instances with the {{PoolManager}}. While the later may not be
> as common for application code, it is more certainly common, and in some
> cases necessary, for framework or tooling code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7159: - Fix Version/s: 1.11.0 > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-7159. -- Resolution: Fixed > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > Fix For: 1.11.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls
[
https://issues.apache.org/jira/browse/GEODE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-7531:
-
Fix Version/s: 1.11.0
> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
> to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all
> {{o.a.g.cache.client.Pools}} registered with the
> {{o.a.g.cache.client.PoolManager}} to be
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly
> "mock" 1 or more {{Pool}} instances and additionally needs to register the
> mock {{Pool}} instances with the {{PoolManager}}. While the later may not be
> as common for application code, it is more certainly common, and in some
> cases necessary, for framework or tooling code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls
[
https://issues.apache.org/jira/browse/GEODE-7531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-7531.
--
Resolution: Fixed
> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> A recent
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
> to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all
> {{o.a.g.cache.client.Pools}} registered with the
> {{o.a.g.cache.client.PoolManager}} to be
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly
> "mock" 1 or more {{Pool}} instances and additionally needs to register the
> mock {{Pool}} instances with the {{PoolManager}}. While the later may not be
> as common for application code, it is more certainly common, and in some
> cases necessary, for framework or tooling code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
Udo Kohlmeyer created GEODE-7752: Summary: Update ConfigurationServiceBuilder to be more intuitive Key: GEODE-7752 URL: https://issues.apache.org/jira/browse/GEODE-7752 Project: Geode Issue Type: Improvement Components: configuration Reporter: Udo Kohlmeyer With the introduction of ClusterManagementServiceBuilder, an inadvertent confusing configuration manner was introduced. In the Builder pattern, the setter methods are optional and required fields are either added on the constructor or build method. The current ClusterManangementServiceBuilder introduced the notion of required optionality. Where you had to pick at least one of the setters. To fix this, I removed `setConnectionConfig` which is really only required for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-7752: Assignee: Udo Kohlmeyer > Update ConfigurationServiceBuilder to be more intuitive > --- > > Key: GEODE-7752 > URL: https://issues.apache.org/jira/browse/GEODE-7752 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > With the introduction of ClusterManagementServiceBuilder, an inadvertent > confusing configuration manner was introduced. > In the Builder pattern, the setter methods are optional and required fields > are either added on the constructor or build method. > The current ClusterManangementServiceBuilder introduced the notion of > required optionality. Where you had to pick at least one of the setters. > To fix this, I removed `setConnectionConfig` which is really only required > for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-7763:
-
Labels: performance (was: )
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test class has 2 primary parameters: [Thread
> Count|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90]
> and the [Workload
> Size|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L91].
> The "_Workload Size_" should not be confused with the "_Payload Size_" of the
> individual objects passed to the Geode data access operations (i.e. {{gets}},
> {{puts}}, {{removes}}). The "_Workload Size_" merely determines the number
> of {{get}}, {{put}} or {{remove}} operations performed on the (Session)
> Region over the duration of the test run. Certain operations are "favored"
> over others, therefore the number of {{gets}}, {{puts}} and {{removes}} is
> weighted.
> The "_Payload_" in this case is a (HTTP) {{Session}} object and the "size" is
> directly proportional to the number of Session attributes stored in the
> Session.
> As you can see from the [test class
> configuration|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L90-L91]
> in *SSDG* {{2.2}}, the *Thread Count* was set to *180* and the *Workload
> Size* (or number of Region operations) was set to *10,000*.
> This had to be significantly adjusted in SSDG 2.3 using Apache Geode 1.11
> (and, as it turns out, Apache Geode 1.10 as well), as can be seen in the
> {{2.3.0.M1}} release bits source,
> [here|https://github.com/spring-projects/spring-session-data-geode/blob/2.3.0.M1/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java#L94-L95].
> It turns out different combinations of the Thread Count (number of workers,
> or "concurrent Sessions") and Workload Size ultimately determine whether this
> test class passes or not.
> In other words, if I increase the Thread Count, then the Workload Size must
> decrease, otherwise the test fails! If I increase the Workload Size, then
> the T
[jira] [Resolved] (GEODE-5129) Amend DistributedTestRule to honor the vmCount paramter < 4
[ https://issues.apache.org/jira/browse/GEODE-5129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-5129. -- Resolution: Fixed Fix Version/s: 1.7.0 > Amend DistributedTestRule to honor the vmCount paramter < 4 > --- > > Key: GEODE-5129 > URL: https://issues.apache.org/jira/browse/GEODE-5129 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-925) CI failure: QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch
[
https://issues.apache.org/jira/browse/GEODE-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-925.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> CI failure:
> QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch
> -
>
> Key: GEODE-925
> URL: https://issues.apache.org/jira/browse/GEODE-925
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Sai Boorlagadda
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: CI, Flaky, pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> {noformat}
> Error Message
> junit.framework.AssertionFailedError: Thread did not terminate after 200 ms:
> Thread[run invoked on an instance of
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest$9,5,]
> Stacktrace
> junit.framework.AssertionFailedError: Thread did not terminate after 200 ms:
> Thread[run invoked on an instance of
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest$9,5,]
> at junit.framework.Assert.fail(Assert.java:57)
> at junit.framework.TestCase.fail(TestCase.java:227)
> at
> com.gemstone.gemfire.test.dunit.DistributedTestCase.join(DistributedTestCase.java:1241)
> at
> com.gemstone.gemfire.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndexWithIndexAndQueryFromCluaseMisMatch(QueryDataInconsistencyDUnitTest.java:386)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:106)
> at sun.reflect.GeneratedMethodAccessor234.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
>
[jira] [Reopened] (GEODE-5059) AbstractRegionMap.basicPut should be refactored
[ https://issues.apache.org/jira/browse/GEODE-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reopened GEODE-5059: -- I'm re-opening this ticket, because I feel that the changes made less correct than expected. I would avoid just adding more methods to the `InternalRegion` and trying to add them to a more logical location and potentially using composition to add functionality. > AbstractRegionMap.basicPut should be refactored > --- > > Key: GEODE-5059 > URL: https://issues.apache.org/jira/browse/GEODE-5059 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: AbstractRegionMap, pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Recently the AbstractRegionMap.basicPut method was refactored into many > smaller methods that all take an instance of RegionMapPutContext. > These methods should be moved to another class (it could be named > RegionMapPut) and the RegionMapPutContext could go away since the > RegionMapPut instance could keep all the state of the put operation. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4791) Update gradle version from 3.5.1 to 4.8
[ https://issues.apache.org/jira/browse/GEODE-4791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-4791: Assignee: Jens Deppe (was: Udo Kohlmeyer) > Update gradle version from 3.5.1 to 4.8 > --- > > Key: GEODE-4791 > URL: https://issues.apache.org/jira/browse/GEODE-4791 > Project: Geode > Issue Type: Improvement > Components: build, general >Reporter: Udo Kohlmeyer >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 3h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
[ https://issues.apache.org/jira/browse/GEODE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-5660: Assignee: Udo Kohlmeyer > Add ability to lookup the GEODE-WEB-API war file from the classpath > --- > > Key: GEODE-5660 > URL: https://issues.apache.org/jira/browse/GEODE-5660 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.8.0 > > > The current AgentUtil class only makes provision to lookup the > `geode-web-api` and `geode-web` war files from known locations. > When referencing the `geode-web-api` and `geode-web` war's from a repository, > the HTTP Services will fail, due to the requirement of having set > `GEODE_HOME` to the locally deployed GEODE distribution. > A way is required to reference the relevant war files from a repository and > not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
Udo Kohlmeyer created GEODE-5660: Summary: Add ability to lookup the GEODE-WEB-API war file from the classpath Key: GEODE-5660 URL: https://issues.apache.org/jira/browse/GEODE-5660 Project: Geode Issue Type: Improvement Components: rest (admin), rest (dev) Reporter: Udo Kohlmeyer Fix For: 1.8.0 The current AgentUtil class only makes provision to lookup the `geode-web-api` and `geode-web` war files from known locations. When referencing the `geode-web-api` and `geode-web` war's from a repository, the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` to the locally deployed GEODE distribution. A way is required to reference the relevant war files from a repository and not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
[ https://issues.apache.org/jira/browse/GEODE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-5660: - Description: The current AgentUtil class only makes provision to lookup the `geode-web-api` and `geode-web` war files from known locations. When referencing the `geode-web-api` and `geode-web` war's from a repository, the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` to the locally deployed GEODE distribution. A way is required to reference the relevant war files from a repository and not requiring the `GEODE_HOME` property to be specifically set. was: The current AgentUtil class only makes provision to lookup the `geode-web-api` and `geode-web` war files from known locations. When referencing the `geode-web-api` and `geode-web` war's from a repository, the HTTP Services will fail, due to the requirement of having set `GEODE_HOME` to the locally deployed GEODE distribution. A way is required to reference the relevant war files from a repository and not requiring the `GEODE_HOME` property to be specifically set. > Add ability to lookup the GEODE-WEB-API war file from the classpath > --- > > Key: GEODE-5660 > URL: https://issues.apache.org/jira/browse/GEODE-5660 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.8.0 > > > The current AgentUtil class only makes provision to lookup the > `geode-web-api` and `geode-web` war files from known locations. > When referencing the `geode-web-api` and `geode-web` war's from a > repository, the HTTP Services will fail, due to the requirement of having set > `GEODE_HOME` to the locally deployed GEODE distribution. > A way is required to reference the relevant war files from a repository and > not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5660) Add ability to lookup the GEODE-WEB-API war file from the classpath
[ https://issues.apache.org/jira/browse/GEODE-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-5660. -- Resolution: Fixed > Add ability to lookup the GEODE-WEB-API war file from the classpath > --- > > Key: GEODE-5660 > URL: https://issues.apache.org/jira/browse/GEODE-5660 > Project: Geode > Issue Type: Improvement > Components: rest (admin), rest (dev) >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > The current AgentUtil class only makes provision to lookup the > `geode-web-api` and `geode-web` war files from known locations. > When referencing the `geode-web-api` and `geode-web` war's from a > repository, the HTTP Services will fail, due to the requirement of having set > `GEODE_HOME` to the locally deployed GEODE distribution. > A way is required to reference the relevant war files from a repository and > not requiring the `GEODE_HOME` property to be specifically set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5705) InternalDataSerializer.basicReadObject convert IF to Switch
Udo Kohlmeyer created GEODE-5705: Summary: InternalDataSerializer.basicReadObject convert IF to Switch Key: GEODE-5705 URL: https://issues.apache.org/jira/browse/GEODE-5705 Project: Geode Issue Type: Improvement Components: serialization Reporter: Udo Kohlmeyer Fix For: 1.8.0 In the InternalDataSerializer.basicReadObject, there are if statements for EVERY DSCODE defined. This has two major problems, * The JIT compiler cannot easily improve this method, due to its size (1.3K) * There is a worst case performance, that every condition is evaluated to read a serialized object. Converting this IF structure to switch the 2nd point is improved. The first point is reduced to 754bytes, which is still not optimal to inline but at least smaller and can still be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5705) InternalDataSerializer.basicReadObject convert IF to Switch
[ https://issues.apache.org/jira/browse/GEODE-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-5705: Assignee: Udo Kohlmeyer > InternalDataSerializer.basicReadObject convert IF to Switch > --- > > Key: GEODE-5705 > URL: https://issues.apache.org/jira/browse/GEODE-5705 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Fix For: 1.8.0 > > > In the InternalDataSerializer.basicReadObject, there are if statements for > EVERY DSCODE defined. This has two major problems, > * The JIT compiler cannot easily improve this method, due to its size (1.3K) > * There is a worst case performance, that every condition is evaluated to > read a serialized object. > Converting this IF structure to switch the 2nd point is improved. The first > point is reduced to 754bytes, which is still not optimal to inline but at > least smaller and can still be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5705) InternalDataSerializer.basicReadObject convert IF to Switch
[ https://issues.apache.org/jira/browse/GEODE-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-5705. -- Resolution: Fixed > InternalDataSerializer.basicReadObject convert IF to Switch > --- > > Key: GEODE-5705 > URL: https://issues.apache.org/jira/browse/GEODE-5705 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 2h > Remaining Estimate: 0h > > In the InternalDataSerializer.basicReadObject, there are if statements for > EVERY DSCODE defined. This has two major problems, > * The JIT compiler cannot easily improve this method, due to its size (1.3K) > * There is a worst case performance, that every condition is evaluated to > read a serialized object. > Converting this IF structure to switch the 2nd point is improved. The first > point is reduced to 754bytes, which is still not optimal to inline but at > least smaller and can still be improved. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5775) Integrate Micrometer into Apache Geode
Udo Kohlmeyer created GEODE-5775: Summary: Integrate Micrometer into Apache Geode Key: GEODE-5775 URL: https://issues.apache.org/jira/browse/GEODE-5775 Project: Geode Issue Type: Improvement Components: management Reporter: Udo Kohlmeyer In order to have better integrations with "off-the-shelf" monitoring solutions, Geode would need to expose the metrics in a better manner. [Micrometer|http://micrometer.io/] provides support for 12 of the most popular monitoring applications in the market. It also supports tagged metrics to provide better aggregations and display of data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5775) Integrate Micrometer into Apache Geode
[ https://issues.apache.org/jira/browse/GEODE-5775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-5775: Assignee: Udo Kohlmeyer > Integrate Micrometer into Apache Geode > -- > > Key: GEODE-5775 > URL: https://issues.apache.org/jira/browse/GEODE-5775 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > In order to have better integrations with "off-the-shelf" monitoring > solutions, Geode would need to expose the metrics in a better manner. > [Micrometer|http://micrometer.io/] provides support for 12 of the most > popular monitoring applications in the market. It also supports tagged > metrics to provide better aggregations and display of data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-7752) Update ConfigurationServiceBuilder to be more intuitive
[ https://issues.apache.org/jira/browse/GEODE-7752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-7752. -- Resolution: Fixed > Update ConfigurationServiceBuilder to be more intuitive > --- > > Key: GEODE-7752 > URL: https://issues.apache.org/jira/browse/GEODE-7752 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Time Spent: 2h 40m > Remaining Estimate: 0h > > With the introduction of ClusterManagementServiceBuilder, an inadvertent > confusing configuration manner was introduced. > In the Builder pattern, the setter methods are optional and required fields > are either added on the constructor or build method. > The current ClusterManangementServiceBuilder introduced the notion of > required optionality. Where you had to pick at least one of the setters. > To fix this, I removed `setConnectionConfig` which is really only required > for the Transport and removed that option. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7159) PoolManager.close(keepAlive) naively assumes all "registered" Pool objects are o.a.g.cache.client.internal.PoolImpl implementations!
[ https://issues.apache.org/jira/browse/GEODE-7159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-7159: - Fix Version/s: 1.12.0 > PoolManager.close(keepAlive) naively assumes all "registered" Pool objects > are o.a.g.cache.client.internal.PoolImpl implementations! > > > Key: GEODE-7159 > URL: https://issues.apache.org/jira/browse/GEODE-7159 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Assignee: Udo Kohlmeyer >Priority: Major > Labels: affects-spring > Fix For: 1.11.0, 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This certainly does not work in a proper "Unit" Test with "mocked" > collaborators! -- This message was sent by Atlassian Jira (v8.3.4#803005)
