[jira] [Commented] (GEODE-9541) CI Failure: SubCommandsIntegrationTest has multiple tests failing intermittently
[
https://issues.apache.org/jira/browse/GEODE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404190#comment-17404190
]
Geode Integration commented on GEODE-9541:
--
Seen in [integration-test-openjdk8
#144|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/144]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0435/test-results/integrationTest/1629847064/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0435/test-artifacts/1629847064/integrationtestfiles-openjdk8-1.15.0-build.0435.tgz].
> CI Failure: SubCommandsIntegrationTest has multiple tests failing
> intermittently
>
>
> Key: GEODE-9541
> URL: https://issues.apache.org/jira/browse/GEODE-9541
> Project: Geode
> Issue Type: Test
> Components: redis, tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This class has become flaky since changes to the netty/radish thread model.
> Failures look like:
> {noformat}
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient(AbstractSubCommandsIntegrationTest.java:320)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern
> FAILED
> java.lang.AssertionError:
> Expecting actual:
> [[102, 42], [102, 111, 111], [98, 97, 114]]
> to contain exactly in any order:
> [[102, 111, 111], [98, 97, 114]]
> but the following elements were unexpected:
> [[102, 42]]
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern(AbstractSubCommandsIntegrationTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers FAILED
> org.junit.ComparisonFailure: expected:<"[0]"> but was:<"[1]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers(AbstractSubCommandsIntegrationTest.java:259)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates FAILED
> org.junit.ComparisonFailure: expected:<[2]L> but was:<[3]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
>
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404188#comment-17404188
]
Xiaojian Zhou commented on GEODE-9320:
--
See in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/145
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> org.apache.geode.redis.internal.executor.string.SetNXNativeRedisAcceptanceTest
> > classMethod FAILED
> 13:40:47org.testcontainers.containers.ContainerLaunchException: Container
> startup failed
> 13:40:47at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> 13:40:47at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:85)
> 13:40:47at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:40:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 13:40:47at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 13:40:47at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
> 13:40:47at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
> 13:40:47at
>
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404189#comment-17404189
]
Geode Integration commented on GEODE-9320:
--
Seen in [acceptance-test-openjdk11
#145|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/145]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0434/test-results/acceptanceTest/1629852506/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0434/test-artifacts/1629852506/acceptancetestfiles-openjdk11-1.15.0-build.0434.tgz].
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> org.apache.geode.redis.internal.executor.string.SetNXNativeRedisAcceptanceTest
> > classMethod FAILED
> 13:40:47org.testcontainers.containers.ContainerLaunchException: Container
> startup failed
> 13:40:47at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> 13:40:47at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:85)
> 13:40:47at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:40:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 13:40:47at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 13:40:47at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
> 13:40:47at
>
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404145#comment-17404145 ] Geode Integration commented on GEODE-8644: -- Seen in [distributed-test-openjdk11 #146|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/146] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0435/test-results/distributedTest/1629853687/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0435/test-artifacts/1629853687/distributedtestfiles-openjdk11-1.15.0-build.0435.tgz]. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9436) Implement ZREMRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9436: -- Labels: pull-request-available (was: ) > Implement ZREMRANGEBYSCORE Command > -- > > Key: GEODE-9436 > URL: https://issues.apache.org/jira/browse/GEODE-9436 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > Implement the [ZREMRANGEBYSCORE|https://redis.io/commands/zremrangebyscore] > command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404105#comment-17404105
]
Dale Emery commented on GEODE-9531:
---
Looking at the test artifacts, I found:
* For some reason, too many tests were run concurrently. The job runs the
{{upgradeTest}} task with test task with {{-PdunitParallelForks=48}}, which
sets a limit of 48 concurrent tests, but Gradle somehow ran as many as 62 tests
concurrently. There were 60 running at the time of this failure.
* This failure happened on the 1.14 support branch. That branch did not include
my changes to upgrade Gradle and to run tests without Dockerizing them. So
those changes don't explain why too many tests ran concurrently.
> CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with
> ForcedDisconnectException
> ---
>
> Key: GEODE-9531
> URL: https://issues.apache.org/jira/browse/GEODE-9531
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$55/2050040059.run
> in VM 2 running on Host 1797ac7f43c4 with 5 VMs
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> Caused by:
> org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> 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-vm2.log' at line 993
> [fatal 2021/05/25 16:58:13.700 GMT
> tid=1349] Membership service failure: Member isn't responding to heartbeat
> requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1783)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:725)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1366)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1302)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 1041
> [error 2021/05/25 16:58:14.206 GMT
> tid=135] Cache initialization for GemFireCache[id = 664332017; isClosing =
> false; isShutDownAll = false; created = Tue May 25 16:57:54 GMT 2021; server
> = false;
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID, compatible-with-redis-user # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. was: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be integrated > with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID, > compatible-with-redis-user > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the default Redis User > (security-username property) and the user provided password > (security-password property) and properly handle the > AuthenticationFailedException. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > When a security manager is configured, redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform redis operations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9548: - Labels: GeodeOperationAPI (was: ) > CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > - > > Key: GEODE-9548 > URL: https://issues.apache.org/jira/browse/GEODE-9548 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > 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-locator.log' at line 435 > [fatal 2021/08/24 20:16:46.325 UTC tid=70] > Exception in processing request from 10.0.0.169 > java.lang.Exception: Improperly configured client detected - use > addPoolLocator to configure its locators instead of addPoolServer. > at > org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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 > junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) > at > junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) > at > junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at >
[jira] [Assigned] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9548: Assignee: Xiaojian Zhou > CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > - > > Key: GEODE-9548 > URL: https://issues.apache.org/jira/browse/GEODE-9548 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > 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-locator.log' at line 435 > [fatal 2021/08/24 20:16:46.325 UTC tid=70] > Exception in processing request from 10.0.0.169 > java.lang.Exception: Improperly configured client detected - use > addPoolLocator to configure its locators instead of addPoolServer. > at > org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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 > junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) > at > junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) > at > junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at >
[jira] [Commented] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404102#comment-17404102 ] Geode Integration commented on GEODE-9548: -- Seen in [distributed-test-openjdk11 #144|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk11/builds/144] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0433/test-results/distributedTest/1629843483/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0433/test-artifacts/1629843483/distributedtestfiles-openjdk11-1.15.0-build.0433.tgz]. > CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > - > > Key: GEODE-9548 > URL: https://issues.apache.org/jira/browse/GEODE-9548 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > 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-locator.log' at line 435 > [fatal 2021/08/24 20:16:46.325 UTC tid=70] > Exception in processing request from 10.0.0.169 > java.lang.Exception: Improperly configured client detected - use > addPoolLocator to configure its locators instead of addPoolServer. > at > org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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 > junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) > at > junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) > at > junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at
[jira] [Created] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
Xiaojian Zhou created GEODE-9548: Summary: CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED Key: GEODE-9548 URL: https://issues.apache.org/jira/browse/GEODE-9548 Project: Geode Issue Type: Bug Components: lucene Reporter: Xiaojian Zhou org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] 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-locator.log' at line 435 [fatal 2021/08/24 20:16:46.325 UTC tid=70] Exception in processing request from 10.0.0.169 java.lang.Exception: Improperly configured client detected - use addPoolLocator to configure its locators instead of addPoolServer. at org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) at org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) at org.junit.Assert.fail(Assert.java:89) at org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) at org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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 junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) at junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) at junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at
[jira] [Updated] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9528:
--
Labels: pull-request-available (was: )
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9532) CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer fails with NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404101#comment-17404101
]
Jianxia Chen commented on GEODE-9532:
-
This is a test issue. Not a product bug.
The async disk store FlusherThread was trying to serialize the instance of
LongWrapper before the LongWrapperSerializer is registered. The
LongWrapperSerializer is registered on vm0 and vm1, when vm0 and vm1 call
Region.get(). When vm2 puts an instance of LongWrapper, the FlusherThread on
vm0 and vm1 could start serializing it before calling Region.get() and
registering the LongWrapperSerializer. The test should make sure
LongWrapperSerializer is registered before serializing any instance of
LongWrapper.
> CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer
> fails with NotSerializableException
> ---
>
> Key: GEODE-9532
> URL: https://issues.apache.org/jira/browse/GEODE-9532
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0
>
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncRegionDUnitTest >
> testNoDataSerializer FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 570
> [fatal 2021/06/15 17:11:03.722 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145]
> Fatal error from asynchronous flusher thread
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2105)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2088)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getSerializedValue(VMCachedDeserializable.java:200)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapper(DiskEntry.java:753)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapperFromEntry(DiskEntry.java:807)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:825)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:815)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeEntryToDisk(DiskEntry.java:1493)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.doAsyncFlush(DiskEntry.java:1445)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1765)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.NotSerializableException:
> org.apache.geode.cache30.MultiVMRegionTestCase$LongWrapper
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at
> org.apache.geode.internal.InternalDataSerializer.writeSerializableObject(InternalDataSerializer.java:2186)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2055)
> at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.util.BlobHelper.serializeToBlob(BlobHelper.java:54)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2103)
> ... 11 more
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 594
> [error 2021/06/15 17:11:03.734 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145] A
> DiskAccessException has occurred while writing to the disk for disk store
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer. The cache will
> be closed.
> org.apache.geode.cache.DiskAccessException: For DiskStore:
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer: Fatal error
> from asynchronous flusher thread, caused by
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1809)
> at
>
[jira] [Resolved] (GEODE-9391) Implement LIMIT Option on Supported Commands
[ https://issues.apache.org/jira/browse/GEODE-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9391. Fix Version/s: 1.15.0 Resolution: Fixed The individual RANGE commands each implemented the LIMIT option when they were done, so this ticket was resolved when the last of them was merged. > Implement LIMIT Option on Supported Commands > > > Key: GEODE-9391 > URL: https://issues.apache.org/jira/browse/GEODE-9391 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: redis > Fix For: 1.15.0 > > > Implement the LIMIT option on ZRANGE, ZREVRANGE, ZRANGEBYSCORE, > ZREVRANGEBYSCORE, ZRANGEBYLEX, and XREVRANGEBYLEX. > > The optional LIMIT argument can be used to obtain a sub-range from the > matching elements (similar to _SELECT LIMIT offset, count_ in SQL). A > negative returns all elements from the . Keep in mind that if > is large, the sorted set needs to be traversed for elements > before getting to the elements to return, which can add up to O(N) time > complexity. > +Acceptance Criteria+ > The LIMIT option has been implemented on the above commands and appropriate > unit tests developed. The redis-cli was used to ensure the LIMIT command > option works correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9389) Implement ZREVRANGEBYLEX Command
[ https://issues.apache.org/jira/browse/GEODE-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9389. Fix Version/s: 1.15.0 Resolution: Fixed > Implement ZREVRANGEBYLEX Command > > > Key: GEODE-9389 > URL: https://issues.apache.org/jira/browse/GEODE-9389 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZREVRANGEBYLEX|https://redis.io/commands/zrevrangebylex] > command without the LIMIT option. > > +Acceptance Criteria+ > The ZREVRANGEBYLEX command has been implemented along with appropriate unit > tests. > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9389) Implement ZREVRANGEBYLEX Command
[ https://issues.apache.org/jira/browse/GEODE-9389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404093#comment-17404093 ] ASF subversion and git services commented on GEODE-9389: Commit 58592edf08e254b0f344cd84fd666db8396daad5 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=58592ed ] GEODE-9389: Implement Radish ZREVRANGEBYLEX Command (#6766) - Introduce AbstractSortedSetRangeExecutor as a parent class for all sorted set range executors - Modify AbstractSortedSetRangeOptions and classes that extend it to reduce code duplication - Make RedisSortedSet range command implementations consistent using AbstractSortedSetRangeOptions - Refactor to allow MemberDummyOrderedSetEntry to always treat scores as equal - Refactor ZCountExecutor and ZLexCountExecutor to extend ZRangeByScoreExecutor and ZRangeByLexExecutor respectively - Refactor zcount() and zlexcount() - Implement Radish ZREVRANGEBYLEX Command - Reorder some methods to maintain alphabetical ordering - Clean up a test in AbstractZRangeByLexIntegrationTest Authored-by: Donal Evans > Implement ZREVRANGEBYLEX Command > > > Key: GEODE-9389 > URL: https://issues.apache.org/jira/browse/GEODE-9389 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available, redis > > Implement the [ZREVRANGEBYLEX|https://redis.io/commands/zrevrangebylex] > command without the LIMIT option. > > +Acceptance Criteria+ > The ZREVRANGEBYLEX command has been implemented along with appropriate unit > tests. > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9547: - Description: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. The ResourcePermission passed to the authorize method should be the same for all operations. The actual permission string is TBD - perhaps DATA:*:GEODE_FOR_REDIS_DATA ?? In the future we may provide more find grained support with different ResourcePermissions for different redis operations. +Acceptance Criteria+ TBD was: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. +Acceptance Criteria+ TBD > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > The ResourcePermission passed to the authorize method should be the same for > all operations. The actual permission string is TBD - perhaps > DATA:*:GEODE_FOR_REDIS_DATA ?? In the future we may provide more find grained > support with different ResourcePermissions for different redis operations. > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the Geode property compatible-with-redis-password that currently being used for the Redis password. # Add a new geode property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ When a security manager is configured, redis clients that don't AUTH with a valid password cannot perform operations. Redis clients that do AUTH with a valid password can perform redis operations. was: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the system property currently being used for the Redis password. # Add a new system property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ TBD > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be implemented > and and integrated with the Geode SecurityManager. > # Remove the Geode property compatible-with-redis-password that currently > being used for the Redis password. > # Add a new geode property for the Redis default user ID. > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the default Redis User > (security-username property) and the user provided password > (security-password property) and properly handle the > AuthenticationFailedException. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > When a security manager is configured, redis clients that don't AUTH with a > valid password cannot perform operations. Redis clients that do AUTH with a > valid password can perform redis operations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
[ https://issues.apache.org/jira/browse/GEODE-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9544: - Description: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the as part of GEODE-9017 and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. was: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the [K8s team|http://https//issues.apache.org/jira/browse/GEODE-9017] and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. > Update Certificate Used by Redis Server when Keystore Changes > - > > Key: GEODE-9544 > URL: https://issues.apache.org/jira/browse/GEODE-9544 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the TLS/SSL Certificate changes in the Java keystore, we want to be able > to automatically update the certificate, used by the server for TLS/SSL, > without requiring a restart of the server. > Although some changes will be necessary, we should be able to reuse much of > the work already implemented by the as part of GEODE-9017 and translate to > the appropriate Netty semantics. > > _Acceptance Criteria_ > A change in the TLS/SSL Certificate, in the keystore, is detected and > automatically applied to the server without requiring a server restart. > > Appropriate tests are written to ensure that this feature works and is not > regressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9542: - Description: When the ssl-require-authentication Geode property is set to true, we should validate the Redis client's certificate against the configured ssl-truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the Geode property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication gemfire property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication Geode property is set to true, we should > validate the Redis client's certificate against the configured ssl-truststore > to ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the Geode property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9542: - Description: When the ssl-require-authentication gemfire property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication gemfire property is set to true, we > should validate the Redis client's certificate against the Java truststore to > ensure that the client certificate is issued by a trusted Certificate > Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the system property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
[ https://issues.apache.org/jira/browse/GEODE-9546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9546: - Description: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the system property currently being used for the Redis password. # Add a new system property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. +Acceptance Criteria+ TBD was: The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the system property currently being used for the Redis password. # Add a new system property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. > Enable Redis Server to Authenticate Using SecurityManager > - > > Key: GEODE-9546 > URL: https://issues.apache.org/jira/browse/GEODE-9546 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > The Redis [AUTH|https://redis.io/commands/auth] command must be implemented > and and integrated with the Geode SecurityManager. > # Remove the system property currently being used for the Redis password. > # Add a new system property for the Redis default user ID. > # When a user issues an AUTH Command, the server must call the authenticate > method on the customer's SecurityManager with the default Redis User > (security-username property) and the user provided password > (security-password property) and properly handle the > AuthenticationFailedException. > # The Object/Principal returned from a successful authenticate method call > must be cached, associated with the client connection, and available for > reuse in subsequent authorization calls. > +Acceptance Criteria+ > > TBD > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9506) CI Failure: BindException in SessionsAndCrashesDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404076#comment-17404076
]
ASF subversion and git services commented on GEODE-9506:
Commit fdda7dbde334311cc1c6ab7a78e28587c96f327d in geode's branch
refs/heads/develop from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fdda7db ]
GEODE-9506: Do not use random ephemeral port to start Redis servers (#6790)
Authored-by: Donal Evans
> CI Failure: BindException in SessionsAndCrashesDUnitTest
>
>
> Key: GEODE-9506
> URL: https://issues.apache.org/jira/browse/GEODE-9506
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: flaky-test, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 3
> running on Host
> heavy-lifter-48e50679-1ba5-54cd-8da2-5aadbb3287e4.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:461)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:270)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:262)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.startRedisVM(RedisClusterStartupRule.java:82)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.startRedisVM(SessionsAndCrashesDUnitTest.java:93)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:154)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> server compatible with Redis using bind address: /127.0.0.1 and port: 35275.
> Please make sure nothing else is running on this address/port combination.
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createBoundChannel(NettyRedisServer.java:222)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createChannel(NettyRedisServer.java:137)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.(NettyRedisServer.java:116)
> at
> org.apache.geode.redis.internal.GeodeRedisServer.(GeodeRedisServer.java:94)
> at
> org.apache.geode.redis.internal.GeodeRedisService.startRedisServer(GeodeRedisService.java:112)
> at
> org.apache.geode.redis.internal.GeodeRedisService.handleEvent(GeodeRedisService.java:96)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2088)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:644)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1471)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:204)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:99)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$6d6c10c2$1(ClusterStartupRule.java:278)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Resolved] (GEODE-9506) CI Failure: BindException in SessionsAndCrashesDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-9506.
Fix Version/s: 1.15.0
Resolution: Fixed
> CI Failure: BindException in SessionsAndCrashesDUnitTest
>
>
> Key: GEODE-9506
> URL: https://issues.apache.org/jira/browse/GEODE-9506
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: flaky-test, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 3
> running on Host
> heavy-lifter-48e50679-1ba5-54cd-8da2-5aadbb3287e4.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:461)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:270)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:262)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.startRedisVM(RedisClusterStartupRule.java:82)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.startRedisVM(SessionsAndCrashesDUnitTest.java:93)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:154)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> server compatible with Redis using bind address: /127.0.0.1 and port: 35275.
> Please make sure nothing else is running on this address/port combination.
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createBoundChannel(NettyRedisServer.java:222)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createChannel(NettyRedisServer.java:137)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.(NettyRedisServer.java:116)
> at
> org.apache.geode.redis.internal.GeodeRedisServer.(GeodeRedisServer.java:94)
> at
> org.apache.geode.redis.internal.GeodeRedisService.startRedisServer(GeodeRedisService.java:112)
> at
> org.apache.geode.redis.internal.GeodeRedisService.handleEvent(GeodeRedisService.java:96)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2088)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:644)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1471)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:204)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:99)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$6d6c10c2$1(ClusterStartupRule.java:278)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> 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
>
[jira] [Updated] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
[ https://issues.apache.org/jira/browse/GEODE-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9547: - Description: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. +Acceptance Criteria+ TBD was: Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. > Enable Redis Server to Authorize Using Security Manager > --- > > Key: GEODE-9547 > URL: https://issues.apache.org/jira/browse/GEODE-9547 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > Every Redis Command/API invocation must be authorized against the customer > provided Security Manager. > > The SecurityManager.authorize method must be called for every Redis API call > using the principal returned by the SecurityManager.authenticate method > during the authentication process. > > +Acceptance Criteria+ > TBD > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9547) Enable Redis Server to Authorize Using Security Manager
Wayne created GEODE-9547: Summary: Enable Redis Server to Authorize Using Security Manager Key: GEODE-9547 URL: https://issues.apache.org/jira/browse/GEODE-9547 Project: Geode Issue Type: New Feature Reporter: Wayne Every Redis Command/API invocation must be authorized against the customer provided Security Manager. The SecurityManager.authorize method must be called for every Redis API call using the principal returned by the SecurityManager.authenticate method during the authentication process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9546) Enable Redis Server to Authenticate Using SecurityManager
Wayne created GEODE-9546: Summary: Enable Redis Server to Authenticate Using SecurityManager Key: GEODE-9546 URL: https://issues.apache.org/jira/browse/GEODE-9546 Project: Geode Issue Type: New Feature Reporter: Wayne The Redis [AUTH|https://redis.io/commands/auth] command must be implemented and and integrated with the Geode SecurityManager. # Remove the system property currently being used for the Redis password. # Add a new system property for the Redis default user ID. # When a user issues an AUTH Command, the server must call the authenticate method on the customer's SecurityManager with the default Redis User (security-username property) and the user provided password (security-password property) and properly handle the AuthenticationFailedException. # The Object/Principal returned from a successful authenticate method call must be cached, associated with the client connection, and available for reuse in subsequent authorization calls. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404068#comment-17404068
]
Barrett Oglesby commented on GEODE-9528:
This is a test issue.
The test currently does:
1. force disconnect
2. assert the MembershipListener for the region is removed
The finally block of GMSMembership.ManagerImpl.forceDisconnect spins off the
DisconnectThread to do the actual disconnect. The MembershipListener is removed
by that thread.
{noformat}
} finally {
new LoggingThread("DisconnectThread", false, () -> {
lifecycleListener.forcedDisconnect();
uncleanShutdown(reason, shutdownCause);
}).start();
}
{noformat}
If there is a delay in the DisconnectThread processing, the test could fail.
Here is the normal flow:
1. The Test worker thread invokes forceDisconnectMember
2. The DisconnectThread removes the MembershipListener
3. The Test worker thread asserts the listener is removed
Here is logging that shows this behavior:
{noformat}
[warn 2021/08/24 13:38:47.445 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
before forceDisconnectMember
[warn 2021/08/24 13:38:47.452 PDT server tid=0x32] XXX
ManagerImpl.forceDisconnect about to uncleanShutdown
[warn 2021/08/24 13:38:47.472 PDT server tid=0x32] XXX
DistributionAdvisor.close removeMembershipListener
advisee=verifyMembershipListenerIsRemovedAfterForceDisconnect
[warn 2021/08/24 13:38:47.566 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
after forceDisconnectMember
[warn 2021/08/24 13:38:47.567 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
assert
{noformat}
If the DisconnectThread has any kind of delay in running, the order changes,
and the test fails:
{noformat}
[warn 2021/08/24 14:05:29.270 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
before forceDisconnectMember
[warn 2021/08/24 14:05:29.382 PDT server tid=0x32] XXX
ManagerImpl.forceDisconnect about to uncleanShutdown
[warn 2021/08/24 14:05:29.392 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
after forceDisconnectMember
[warn 2021/08/24 14:05:29.393 PDT server tid=0xb] XXX
DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect
assert
[warn 2021/08/24 14:05:29.403 PDT server tid=0x32] XXX
DistributionAdvisor.close removeMembershipListener
advisee=verifyMembershipListenerIsRemovedAfterForceDisconnect
org.junit.ComparisonFailure:
Expecting value to be false but was true expected:<[fals]e> but was:<[tru]e>
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.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:62)
{noformat}
The fix is to add await().untilAsserted like:
{noformat}
await().untilAsserted(
() ->
assertThat(manager.getMembershipListeners().contains(listener)).isFalse());
{noformat}
With the introduced delay, the test failed 80/100 times. With the await change,
the test passed 100/100 times.
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This
[jira] [Updated] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
[ https://issues.apache.org/jira/browse/GEODE-9544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9544: - Description: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the [K8s team|http://https//issues.apache.org/jira/browse/GEODE-9017] and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. was: When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the K8s team and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. > Update Certificate Used by Redis Server when Keystore Changes > - > > Key: GEODE-9544 > URL: https://issues.apache.org/jira/browse/GEODE-9544 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the TLS/SSL Certificate changes in the Java keystore, we want to be able > to automatically update the certificate, used by the server for TLS/SSL, > without requiring a restart of the server. > Although some changes will be necessary, we should be able to reuse much of > the work already implemented by the [K8s > team|http://https//issues.apache.org/jira/browse/GEODE-9017] and translate to > the appropriate Netty semantics. > > _Acceptance Criteria_ > A change in the TLS/SSL Certificate, in the keystore, is detected and > automatically applied to the server without requiring a server restart. > > Appropriate tests are written to ensure that this feature works and is not > regressed. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9506) CI Failure: BindException in SessionsAndCrashesDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-9506:
--
Assignee: Donal Evans
> CI Failure: BindException in SessionsAndCrashesDUnitTest
>
>
> Key: GEODE-9506
> URL: https://issues.apache.org/jira/browse/GEODE-9506
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: flaky-test, pull-request-available
>
> {noformat}
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest >
> sessionOperationsDoNotFail_whileServersAreRestarted FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call in VM 3
> running on Host
> heavy-lifter-48e50679-1ba5-54cd-8da2-5aadbb3287e4.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:461)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:270)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.startServerVM(ClusterStartupRule.java:262)
> at
> org.apache.geode.test.dunit.rules.RedisClusterStartupRule.startRedisVM(RedisClusterStartupRule.java:82)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.startRedisVM(SessionsAndCrashesDUnitTest.java:93)
> at
> org.apache.geode.redis.session.SessionsAndCrashesDUnitTest.sessionOperationsDoNotFail_whileServersAreRestarted(SessionsAndCrashesDUnitTest.java:154)
> Caused by:
> org.apache.geode.management.ManagementException: Could not start
> server compatible with Redis using bind address: /127.0.0.1 and port: 35275.
> Please make sure nothing else is running on this address/port combination.
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createBoundChannel(NettyRedisServer.java:222)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.createChannel(NettyRedisServer.java:137)
> at
> org.apache.geode.redis.internal.netty.NettyRedisServer.(NettyRedisServer.java:116)
> at
> org.apache.geode.redis.internal.GeodeRedisServer.(GeodeRedisServer.java:94)
> at
> org.apache.geode.redis.internal.GeodeRedisService.startRedisServer(GeodeRedisService.java:112)
> at
> org.apache.geode.redis.internal.GeodeRedisService.handleEvent(GeodeRedisService.java:96)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2088)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:644)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1471)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.startServer(ServerStarterRule.java:204)
> at
> org.apache.geode.test.junit.rules.ServerStarterRule.before(ServerStarterRule.java:99)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startServerVM$6d6c10c2$1(ClusterStartupRule.java:278)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> 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.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> 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
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
>
[jira] [Assigned] (GEODE-9391) Implement LIMIT Option on Supported Commands
[ https://issues.apache.org/jira/browse/GEODE-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9391: -- Assignee: Donal Evans > Implement LIMIT Option on Supported Commands > > > Key: GEODE-9391 > URL: https://issues.apache.org/jira/browse/GEODE-9391 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: redis > > Implement the LIMIT option on ZRANGE, ZREVRANGE, ZRANGEBYSCORE, > ZREVRANGEBYSCORE, ZRANGEBYLEX, and XREVRANGEBYLEX. > > The optional LIMIT argument can be used to obtain a sub-range from the > matching elements (similar to _SELECT LIMIT offset, count_ in SQL). A > negative returns all elements from the . Keep in mind that if > is large, the sorted set needs to be traversed for elements > before getting to the elements to return, which can add up to O(N) time > complexity. > +Acceptance Criteria+ > The LIMIT option has been implemented on the above commands and appropriate > unit tests developed. The redis-cli was used to ensure the LIMIT command > option works correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9545) Prevent introduction of unsanctioned serializables that break validate-serializable-objects
Kirk Lund created GEODE-9545: Summary: Prevent introduction of unsanctioned serializables that break validate-serializable-objects Key: GEODE-9545 URL: https://issues.apache.org/jira/browse/GEODE-9545 Project: Geode Issue Type: Wish Components: build Reporter: Kirk Lund The fix for GEODE-9486 ensures that all Geode product serializables are accept-listed for validate-serizable-objects. GEODE-9486 could still be re-introduced for new Geode modules or existing modules that don't currently have a sanctioned serializables list along with a corresponding Analyze*SerializablesIntegrationTest for the module. This ticket is a wish for some overall build mechanism that prevents regressions of this sort. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9112) Port testThinClientAfterRegionLive to new framework
[ https://issues.apache.org/jira/browse/GEODE-9112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-9112. --- > Port testThinClientAfterRegionLive to new framework > --- > > Key: GEODE-9112 > URL: https://issues.apache.org/jira/browse/GEODE-9112 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Assignee: Matthew Reddington >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8318) Shutdown hang and abort
[ https://issues.apache.org/jira/browse/GEODE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-8318. --- > Shutdown hang and abort > --- > > Key: GEODE-8318 > URL: https://issues.apache.org/jira/browse/GEODE-8318 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Matthew Reddington >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Switching from Ace to Boost.Asio has revealed threading issues related to > shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9112) Port testThinClientAfterRegionLive to new framework
[ https://issues.apache.org/jira/browse/GEODE-9112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-9112. - Resolution: Fixed https://github.com/apache/geode-native/pull/805 > Port testThinClientAfterRegionLive to new framework > --- > > Key: GEODE-9112 > URL: https://issues.apache.org/jira/browse/GEODE-9112 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Assignee: Matthew Reddington >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9544) Update Certificate Used by Redis Server when Keystore Changes
Wayne created GEODE-9544: Summary: Update Certificate Used by Redis Server when Keystore Changes Key: GEODE-9544 URL: https://issues.apache.org/jira/browse/GEODE-9544 Project: Geode Issue Type: New Feature Reporter: Wayne When the TLS/SSL Certificate changes in the Java keystore, we want to be able to automatically update the certificate, used by the server for TLS/SSL, without requiring a restart of the server. Although some changes will be necessary, we should be able to reuse much of the work already implemented by the K8s team and translate to the appropriate Netty semantics. _Acceptance Criteria_ A change in the TLS/SSL Certificate, in the keystore, is detected and automatically applied to the server without requiring a server restart. Appropriate tests are written to ensure that this feature works and is not regressed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-9531.
-
Resolution: Not A Bug
> CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with
> ForcedDisconnectException
> ---
>
> Key: GEODE-9531
> URL: https://issues.apache.org/jira/browse/GEODE-9531
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$55/2050040059.run
> in VM 2 running on Host 1797ac7f43c4 with 5 VMs
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> Caused by:
> org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> 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-vm2.log' at line 993
> [fatal 2021/05/25 16:58:13.700 GMT
> tid=1349] Membership service failure: Member isn't responding to heartbeat
> requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1783)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:725)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1366)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1302)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 1041
> [error 2021/05/25 16:58:14.206 GMT
> tid=135] Cache initialization for GemFireCache[id = 664332017; isClosing =
> false; isShutDownAll = false; created = Tue May 25 16:57:54 GMT 2021; server
> = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed
> because:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl.checkCancelled(DistributionImpl.java:313)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:243)
> at
>
[jira] [Updated] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu updated GEODE-9531:
Labels: GeodeOperationAPI (was: GeodeOperationAPI blocks-1.14.0)
> CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with
> ForcedDisconnectException
> ---
>
> Key: GEODE-9531
> URL: https://issues.apache.org/jira/browse/GEODE-9531
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$55/2050040059.run
> in VM 2 running on Host 1797ac7f43c4 with 5 VMs
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> Caused by:
> org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> 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-vm2.log' at line 993
> [fatal 2021/05/25 16:58:13.700 GMT
> tid=1349] Membership service failure: Member isn't responding to heartbeat
> requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1783)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:725)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1366)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1302)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 1041
> [error 2021/05/25 16:58:14.206 GMT
> tid=135] Cache initialization for GemFireCache[id = 664332017; isClosing =
> false; isShutDownAll = false; created = Tue May 25 16:57:54 GMT 2021; server
> = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed
> because:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl.checkCancelled(DistributionImpl.java:313)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:243)
> at
>
[jira] [Commented] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404051#comment-17404051
]
Eric Shu commented on GEODE-9531:
-
This is a resource issue as multiple vms (in various tests at the time) all
encountered same suspect process.
For the failing test, the vm failed was just starting up joined the ds:
{noformat}
[vm2] [info 2021/05/25 16:57:54.603 GMT
tid=0x87] DistributionManager 172.17.0.39(278):41003 started on
localhost[43925]. There were 3 other DMs. others:
[172.17.0.39(255):41002, 172.17.0.39(246):41001,
1797ac7f43c4(107:locator):41000] (took 1800 ms)
[vm2] [info 2021/05/25 16:57:54.850 GMT tid=0x556] Disabling
statistic archival.
[vm2] [info 2021/05/25 16:57:54.896 GMT
tid=0x87] No locator(s) found with cluster configuration service
[vm2] [info 2021/05/25 16:57:55.161 GMT
tid=0x87] Initialized cache service
org.apache.geode.cache.query.internal.QueryConfigurationServiceImpl
{noformat}
And at the time all vms got suspected as Geode Failure Detection kicked in.
{noformat}
[vm1] [info 2021/05/25 16:58:08.119 GMT
tid=0x76b] received suspect message from myself for
1797ac7f43c4(107:locator):41000: Member isn't responding to heartbeat
requests
[vm1] [info 2021/05/25 16:58:08.118 GMT
tid=0x76a] received suspect message from myself for
172.17.0.39(278):41003: Member isn't responding to heartbeat requests
[vm1] [info 2021/05/25 16:58:08.143 GMT
tid=0x76c] received suspect message from myself for
172.17.0.39(246):41001: Member isn't responding to heartbeat requests
[vm1] [info 2021/05/25 16:58:08.264 GMT
tid=0x76a] Performing availability check for suspect member
172.17.0.39(278):41003 reason=Member isn't responding to heartbeat
requests
[vm1] [info 2021/05/25 16:58:08.266 GMT
tid=0x76a] All other members are suspect at this point
{noformat}
locator did not get enough cpu cycles as well, but managed to respond the
suspect process just in time.
{noformat}
[locator] [warn 2021/05/25 16:58:11.415 GMT tid=0x37]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 15,705,239,045 nanoseconds. Period: 2,500,000,000
nanoseconds.
[locator] [info 2021/05/25 16:58:11.541 GMT tid=0x32] received suspect message from
172.17.0.39(255):41002 for 172.17.0.39(278):41003: Member isn't
responding to heartbeat requests
{noformat}
vm2 did not and so it was kicked out of the ds.
{noformat}
[vm2] [warn 2021/05/25 16:58:13.131 GMT tid=0x556] Statistics
sampling thread detected a wakeup delay of 16556 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
[vm2] [warn 2021/05/25 16:58:13.147 GMT tid=0x54a]
Failure detection heartbeat-generation thread overslept by more than a full
period. Asleep time: 19,938,476,329 nanoseconds. Period: 2,500,000,000
nanoseconds.
[vm1] [info 2021/05/25 16:58:13.351 GMT
tid=0x76a] Availability check failed for member 172.17.0.39(278):41003
[vm1] [info 2021/05/25 16:58:13.351 GMT
tid=0x76a] Requesting removal of suspect member 172.17.0.39(278):41003
{noformat}
I also tried to see if other tests run experiencing the same issue or not. At
the time, following tests are run concurrently.
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled
luceneQueryReturnsCorrectResultAfterTwoLocatorsWithTwoServersAreRolled[from_v1.3.0,
with reindex=true, singleHopEnabled=true]
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver
luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver[from_v1.3.0,
with reindex=true, singleHopEnabled=true]
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
test[from_v1.4.0, with reindex=true, singleHopEnabled=true]
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[from_v1.2.0,
with reindex=false, singleHopEnabled=true]
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPersistentPartitionRegion
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPersistentPartitionRegion[from_v1.2.0,
with reindex=false, singleHopEnabled=true]
org.apache.geode.cache.lucene.RollingUpgradeReindexShouldBeSuccessfulWhenAllServersRollToCurrentVersion
luceneReindexShouldBeSuccessfulWhenAllServersRollToCurrentVersion[from_v1.3.0,
with reindex=false, singleHopEnabled=true]
org.apache.geode.cache.wan.WANRollingUpgradeCreateGatewaySenderMixedSiteOneCurrentSiteTwo
CreateGatewaySenderMixedSiteOneCurrentSiteTwo[from_v1.8.0]
org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo
EventProcessingMixedSiteOneCurrentSiteTwo[from_v1.7.0]
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9542: - Description: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. When the system property ssl-require-authentication is set to false, no client certificate authentication is performed. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. Appropriate tests are developed to ensure this feature works as expected and does not regress. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication system property is set to true, we should > validate the Redis client's certificate against the Java truststore to ensure > that the client certificate is issued by a trusted Certificate Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. When the system property > ssl-require-authentication is set to false, no client certificate > authentication is performed. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9543) CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED
[ https://issues.apache.org/jira/browse/GEODE-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9543. -- Resolution: Duplicate duplicated with GEODE-9541 > CI: > org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > FAILED > - > > Key: GEODE-9543 > URL: https://issues.apache.org/jira/browse/GEODE-9543 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > > It's found in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140 > org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > > numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) >
[jira] [Updated] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
[ https://issues.apache.org/jira/browse/GEODE-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9542: - Description: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. Client certificates issued by non-trusted Certificate Authorities are not authenticated. Appropriate tests are developed to ensure this feature works as expected and does not regress. was: When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. > Enable SSL Client Certificate Authorization for Redis > - > > Key: GEODE-9542 > URL: https://issues.apache.org/jira/browse/GEODE-9542 > Project: Geode > Issue Type: New Feature >Reporter: Wayne >Priority: Major > > When the ssl-require-authentication system property is set to true, we should > validate the Redis client's certificate against the Java truststore to ensure > that the client certificate is issued by a trusted Certificate Authority. > > _Acceptance Criteria_ > Client certificates issued by trusted Certificate Authorities are properly > authenticated. Client certificates issued by non-trusted Certificate > Authorities are not authenticated. > Appropriate tests are developed to ensure this feature works as expected and > does not regress. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9543) CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED
Xiaojian Zhou created GEODE-9543: Summary: CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED Key: GEODE-9543 URL: https://issues.apache.org/jira/browse/GEODE-9543 Project: Geode Issue Type: Bug Components: redis Reporter: Xiaojian Zhou It's found in https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140 org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119) at
[jira] [Created] (GEODE-9542) Enable SSL Client Certificate Authorization for Redis
Wayne created GEODE-9542: Summary: Enable SSL Client Certificate Authorization for Redis Key: GEODE-9542 URL: https://issues.apache.org/jira/browse/GEODE-9542 Project: Geode Issue Type: New Feature Reporter: Wayne When the ssl-require-authentication system property is set to true, we should validate the Redis client's certificate against the Java truststore to ensure that the client certificate is issued by a trusted Certificate Authority. _Acceptance Criteria_ Client certificates issued by trusted Certificate Authorities are properly authenticated. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9541) CI Failure: SubCommandsIntegrationTest has multiple tests failing intermittently
[
https://issues.apache.org/jira/browse/GEODE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404031#comment-17404031
]
Geode Integration commented on GEODE-9541:
--
Seen in [integration-test-openjdk8
#140|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-results/integrationTest/1629827589/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-artifacts/1629827589/integrationtestfiles-openjdk8-1.15.0-build.0431.tgz].
> CI Failure: SubCommandsIntegrationTest has multiple tests failing
> intermittently
>
>
> Key: GEODE-9541
> URL: https://issues.apache.org/jira/browse/GEODE-9541
> Project: Geode
> Issue Type: Test
> Components: redis, tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This class has become flaky since changes to the netty/radish thread model.
> Failures look like:
> {noformat}
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient(AbstractSubCommandsIntegrationTest.java:320)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern
> FAILED
> java.lang.AssertionError:
> Expecting actual:
> [[102, 42], [102, 111, 111], [98, 97, 114]]
> to contain exactly in any order:
> [[102, 111, 111], [98, 97, 114]]
> but the following elements were unexpected:
> [[102, 42]]
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern(AbstractSubCommandsIntegrationTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers FAILED
> org.junit.ComparisonFailure: expected:<"[0]"> but was:<"[1]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers(AbstractSubCommandsIntegrationTest.java:259)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates FAILED
> org.junit.ComparisonFailure: expected:<[2]L> but was:<[3]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
>
[jira] [Assigned] (GEODE-9541) CI Failure: SubCommandsIntegrationTest has multiple tests failing intermittently
[
https://issues.apache.org/jira/browse/GEODE-9541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9541:
-
Assignee: Jens Deppe
> CI Failure: SubCommandsIntegrationTest has multiple tests failing
> intermittently
>
>
> Key: GEODE-9541
> URL: https://issues.apache.org/jira/browse/GEODE-9541
> Project: Geode
> Issue Type: Test
> Components: redis, tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>
> This class has become flaky since changes to the netty/radish thread model.
> Failures look like:
> {noformat}
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient FAILED
> org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient(AbstractSubCommandsIntegrationTest.java:320)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern
> FAILED
> java.lang.AssertionError:
> Expecting actual:
> [[102, 42], [102, 111, 111], [98, 97, 114]]
> to contain exactly in any order:
> [[102, 111, 111], [98, 97, 114]]
> but the following elements were unexpected:
> [[102, 42]]
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern(AbstractSubCommandsIntegrationTest.java:126)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers FAILED
> org.junit.ComparisonFailure: expected:<"[0]"> but was:<"[1]">
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers(AbstractSubCommandsIntegrationTest.java:259)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates FAILED
> org.junit.ComparisonFailure: expected:<[2]L> but was:<[3]L>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates(AbstractSubCommandsIntegrationTest.java:302)
>
> org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
> channels_shouldOnlyReturnChannelsWithActiveSubscribers FAILED
> java.lang.AssertionError:
> Expecting actual:
> [[102,
[jira] [Issue Comment Deleted] (GEODE-9169) Remove Context Switch Between Netty and Command Queue Thread
[ https://issues.apache.org/jira/browse/GEODE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9169: -- Comment: was deleted (was: Seen in [integration-test-openjdk8 #140|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-results/integrationTest/1629827589/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-artifacts/1629827589/integrationtestfiles-openjdk8-1.15.0-build.0431.tgz].) > Remove Context Switch Between Netty and Command Queue Thread > > > Key: GEODE-9169 > URL: https://issues.apache.org/jira/browse/GEODE-9169 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.15.0, performance, pull-request-available, > redis > Fix For: 1.15.0 > > > On the current develop branch, the Netty thread reads a message and then puts > it on a queue for another thread to process. Performing the region update > directly on the Netty thread significantly improved performance. > The original behavior was there to support pub/sub use cases, where we need > to push updates to the Netty channel, as well as following Netty best > practices of not blocking the Netty thread. We need to see how we can make > this same change on develop to avoid the context switch while still > supporting pub/sub and not breaking other use cases. > +Acceptance Criteria+ > The context switch between the Netty and command queue thread has been > removed for all commands that are not pub/sub related. > Geode benchmarks perform better after this change for all non-pubsub commands. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9541) CI Failure: SubCommandsIntegrationTest has multiple tests failing intermittently
Jens Deppe created GEODE-9541:
-
Summary: CI Failure: SubCommandsIntegrationTest has multiple tests
failing intermittently
Key: GEODE-9541
URL: https://issues.apache.org/jira/browse/GEODE-9541
Project: Geode
Issue Type: Test
Components: redis, tests
Reporter: Jens Deppe
This class has become flaky since changes to the netty/radish thread model.
Failures look like:
{noformat}
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED
org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334)
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient FAILED
org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forDifferentClient(AbstractSubCommandsIntegrationTest.java:320)
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern
FAILED
java.lang.AssertionError:
Expecting actual:
[[102, 42], [102, 111, 111], [98, 97, 114]]
to contain exactly in any order:
[[102, 111, 111], [98, 97, 114]]
but the following elements were unexpected:
[[102, 42]]
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.channels_shouldReturnListOfAllChannels_withActiveChannelSubscribers_whenCalledWithoutPattern(AbstractSubCommandsIntegrationTest.java:126)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers FAILED
org.junit.ComparisonFailure: expected:<"[0]"> but was:<"[1]">
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numsub_shouldReturnZero_whenCalledWithPatternWithNoChannelSubscribers(AbstractSubCommandsIntegrationTest.java:259)
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates FAILED
org.junit.ComparisonFailure: expected:<[2]L> but was:<[3]L>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldReturnCountOfAllPatternSubscriptions_includingDuplicates(AbstractSubCommandsIntegrationTest.java:302)
org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest >
channels_shouldOnlyReturnChannelsWithActiveSubscribers FAILED
java.lang.AssertionError:
Expecting actual:
[[102, 42], [98, 97, 114]]
to contain exactly in any order:
[[98, 97, 114]]
but the following elements were unexpected:
[[102, 42]]
at
org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.channels_shouldOnlyReturnChannelsWithActiveSubscribers(AbstractSubCommandsIntegrationTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] [Updated] (GEODE-9537) CqDataUsingPoolDUnitTest (and CqDataUsingPoolOptimizedExecuteDUnitTest) should not use ephemeral ports
[
https://issues.apache.org/jira/browse/GEODE-9537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9537:
--
Labels: pull-request-available (was: )
> CqDataUsingPoolDUnitTest (and CqDataUsingPoolOptimizedExecuteDUnitTest)
> should not use ephemeral ports
> --
>
> Key: GEODE-9537
> URL: https://issues.apache.org/jira/browse/GEODE-9537
> Project: Geode
> Issue Type: Test
> Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> These tests currently use ephemeral ports for components that are stopped and
> restarted during the test. It can happen that other, concurrently running
> tests, will start using these same ports causing test failures (but not in
> the tests mentioned here).
> Test failures appear as dunit suspect strings:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-locator.log' at line 347
> [fatal 2021/08/21 19:46:08.527 UTC tid=47]
> Exception in processing request from 10.0.0.107
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-9528:
--
Assignee: Barrett Oglesby (was: Ernest Burghardt)
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Barrett Oglesby
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9169) Remove Context Switch Between Netty and Command Queue Thread
[ https://issues.apache.org/jira/browse/GEODE-9169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404018#comment-17404018 ] Geode Integration commented on GEODE-9169: -- Seen in [integration-test-openjdk8 #140|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-results/integrationTest/1629827589/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0431/test-artifacts/1629827589/integrationtestfiles-openjdk8-1.15.0-build.0431.tgz]. > Remove Context Switch Between Netty and Command Queue Thread > > > Key: GEODE-9169 > URL: https://issues.apache.org/jira/browse/GEODE-9169 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.15.0, performance, pull-request-available, > redis > Fix For: 1.15.0 > > > On the current develop branch, the Netty thread reads a message and then puts > it on a queue for another thread to process. Performing the region update > directly on the Netty thread significantly improved performance. > The original behavior was there to support pub/sub use cases, where we need > to push updates to the Netty channel, as well as following Netty best > practices of not blocking the Netty thread. We need to see how we can make > this same change on develop to avoid the context switch while still > supporting pub/sub and not breaking other use cases. > +Acceptance Criteria+ > The context switch between the Netty and command queue thread has been > removed for all commands that are not pub/sub related. > Geode benchmarks perform better after this change for all non-pubsub commands. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9539) Remove Radish test SupportedCommandsJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404015#comment-17404015 ] ASF subversion and git services commented on GEODE-9539: Commit 7f4afe629ff9bd6dd501383ea456ea1f9070ef8d in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7f4afe6 ] GEODE-9539: Remove Radish SupportedCommandsJUnitTest (#6795) > Remove Radish test SupportedCommandsJUnitTest > - > > Key: GEODE-9539 > URL: https://issues.apache.org/jira/browse/GEODE-9539 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > This test doesn't serve any useful purpose anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-1505) Fix spelling of IndexMaintainceJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404014#comment-17404014 ] ASF subversion and git services commented on GEODE-1505: Commit 20ee160c296ee94c9d1ae946f4ca8a04d319d411 in geode's branch refs/heads/develop from dkhopade [ https://gitbox.apache.org/repos/asf?p=geode.git;h=20ee160 ] GEODE-1505: merged 2 classes. moved the tests from incorrectly spelled test class (#6757) * merged 2 classes. moved the tests from incorrectly spelled test class * ran ./gradlew spotlessApply per review comments on PR * fixed the test names per review comments by Donal Evans * renamed test cases to more appropriate names as per review comments received Co-authored-by: Deepak Khopade > Fix spelling of IndexMaintainceJUnitTest > > > Key: GEODE-1505 > URL: https://issues.apache.org/jira/browse/GEODE-1505 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available, starter > Fix For: 1.15.0 > > > IndexMaintainceJUnitTest should be renamed to IndexMaintenanceJUnitTest. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-1505) Fix spelling of IndexMaintainceJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-1505. - Fix Version/s: 1.15.0 Resolution: Fixed > Fix spelling of IndexMaintainceJUnitTest > > > Key: GEODE-1505 > URL: https://issues.apache.org/jira/browse/GEODE-1505 > Project: Geode > Issue Type: Task > Components: tests >Reporter: Kirk Lund >Priority: Major > Labels: pull-request-available, starter > Fix For: 1.15.0 > > > IndexMaintainceJUnitTest should be renamed to IndexMaintenanceJUnitTest. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403993#comment-17403993
]
Ernest Burghardt commented on GEODE-9528:
-
This is not reproducing on 1.14
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Ernest Burghardt
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403993#comment-17403993
]
Ernest Burghardt edited comment on GEODE-9528 at 8/24/21, 6:24 PM:
---
This is not reproducing on 1.14 over multiple thousands of runs.
was (Author: eburghardt):
This is not reproducing on 1.14
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Ernest Burghardt
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-9528:
Labels: (was: blocks-1.12.5 blocks-1.13.5 blocks-1.14.0)
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Ernest Burghardt
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9458) Add tests for functions executions on servers when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-9458: --- Description: and make sure the behavior matches expectation. make sure to include tests in multi-server cases test onServer, onServers, onRegions was: and make sure the behavior matches expectation. make sure to include tests in multi-server cases > Add tests for functions executions on servers when authentication expires > - > > Key: GEODE-9458 > URL: https://issues.apache.org/jira/browse/GEODE-9458 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > and make sure the behavior matches expectation. > > make sure to include tests in multi-server cases > > test onServer, onServers, onRegions -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9540) verify client bulk operations like putAll and getAll and succeed after authentication expires
Jinmei Liao created GEODE-9540: -- Summary: verify client bulk operations like putAll and getAll and succeed after authentication expires Key: GEODE-9540 URL: https://issues.apache.org/jira/browse/GEODE-9540 Project: Geode Issue Type: Sub-task Components: security Reporter: Jinmei Liao -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reopened GEODE-9456: > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-9452: -- Assignee: Jinmei Liao > The older version client should receive the AuthenticationRequiredException > when authentication expires > --- > > Key: GEODE-9452 > URL: https://issues.apache.org/jira/browse/GEODE-9452 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI > > Currently, for older client, it's receiving a ClassNotFoundException, we need > to add the serialization code to convert the AuthenticationExpiredException > into this old exception type that the older clients can understand. > > Note: when converting the exception, if we have the message to match what the > older client expects, it can do re-authentication automatically, but we lost > the original message that server has thrown. (Need to consult the PM on what > kind of behavior they want). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-9456: -- Assignee: Jinmei Liao > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9456) Create AuthenticationExpiredException and have the client handle that exception for re-authentication
[ https://issues.apache.org/jira/browse/GEODE-9456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9456. Resolution: Fixed > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > - > > Key: GEODE-9456 > URL: https://issues.apache.org/jira/browse/GEODE-9456 > Project: Geode > Issue Type: Sub-task > Components: core, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Create AuthenticationExpiredException and have the client handle that > exception for re-authentication > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9442) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403957#comment-17403957 ] ASF subversion and git services commented on GEODE-9442: Commit 6f77c99b2da6301d252d8b6653c5416b2a2c0bf6 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6f77c99 ] GEODE-9442: Add logging when Native Redis container is stopped (#6791) Authored-by: Donal Evans > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9442 > URL: https://issues.apache.org/jira/browse/GEODE-9442 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Labels: pull-request-available > > This acceptance-test-openjdk8 failed due to timeout. > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/88 > It does not appear to be one particular test hang -- as all running tests are > finished showing status of SUCCESS. > There are 1153 tests shown being run in this run. > Test Summary > 1153 > tests > The previous run showed 1295 tests were run. > Test Summary > 1295 > tests > However, it shows that gradle no able to shut down one test worker: > in daemon-4088.out.log under .gradle_logs directory following exception was > seen: > Daemon is stopping immediately stop command received > Daemon vm is shutting down... The daemon has exited normally or was > terminated in response to a user interrupt. > failed to abort Gradle Test Executor 143 > org.gradle.process.internal.ExecException: A problem occurred waiting for > process 'Gradle Test Executor 143' to complete. > at > org.gradle.process.internal.DefaultExecHandle.execExceptionFor(DefaultExecHandle.java:241) > at > org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:218) > at > org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:369) > at > org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:87) > at > org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) > at > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: Shutdown in progress > at > java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82) > at java.lang.Runtime.removeShutdownHook(Runtime.java:239) > at > org.gradle.process.internal.shutdown.ShutdownHooks.removeShutdownHook(ShutdownHooks.java:33) > at > org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:208) > at > org.gradle.process.internal.DefaultExecHandle.aborted(DefaultExecHandle.java:365) > at > org.gradle.process.internal.ExecHandleRunner.completed(ExecHandleRunner.java:108) > at > org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:84) > ... 7 more > Also, in > geode-apis-compatible-with-redis/build/test-results/acceptanceTest/binary > output.bin file that Redis container was started but no further information > for its shutdown. No sure if this is normal or not. > ^A<9c>^H^@<8a>^A[info 2021/07/20 16:55:00.011 UTC tid=0xa] > Ryuk started - will monitor and terminate Testcontainers containers on JVM > exit > ^A<9c>^H^@^A > ^A<9c>^H^@Q[info 2021/07/20 16:55:00.012 UTC tid=0xa] Checking > the system... > ^A<9c>^H^@^A > ^A<9c>^H^@p[info 2021/07/20 16:55:00.013 UTC tid=0xa] > â<9c><94>ï¸<8e> Docker server version should be at least 1.6.0 > ^A<9c>^H^@^A > ^A<9c>^H^@~[info 2021/07/20 16:55:00.142 UTC tid=0xa] > â<9c><94>ï¸<8e> Docker environment should have more than 2GB free disk space > ^A<9c>^H^@^A > ^A<9c>^H^@d[info 2021/07/20 16:55:00.161 UTC tid=0xa] Creating > container for image: redis:5.0.6 > ^A<9c>^H^@^A > ^A<9c>^H^@<97>^A[info 2021/07/20 16:55:00.218 UTC tid=0xa] > Starting container with ID: > 3d1530c27f0b4f6e526bfc48b8232708abd3e0de55f188c74e007db30a19d634 > ^A<9c>^H^@^A > ^A<9c>^H^@<9e>^A[info 2021/07/20 16:55:00.658 UTC tid=0xa] > Container redis:5.0.6 is starting: >
[jira] [Resolved] (GEODE-9442) CI Failure: acceptance-test-openjdk8 timed out
[ https://issues.apache.org/jira/browse/GEODE-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9442. Fix Version/s: 1.15.0 Resolution: Resolved > CI Failure: acceptance-test-openjdk8 timed out > -- > > Key: GEODE-9442 > URL: https://issues.apache.org/jira/browse/GEODE-9442 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This acceptance-test-openjdk8 failed due to timeout. > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/88 > It does not appear to be one particular test hang -- as all running tests are > finished showing status of SUCCESS. > There are 1153 tests shown being run in this run. > Test Summary > 1153 > tests > The previous run showed 1295 tests were run. > Test Summary > 1295 > tests > However, it shows that gradle no able to shut down one test worker: > in daemon-4088.out.log under .gradle_logs directory following exception was > seen: > Daemon is stopping immediately stop command received > Daemon vm is shutting down... The daemon has exited normally or was > terminated in response to a user interrupt. > failed to abort Gradle Test Executor 143 > org.gradle.process.internal.ExecException: A problem occurred waiting for > process 'Gradle Test Executor 143' to complete. > at > org.gradle.process.internal.DefaultExecHandle.execExceptionFor(DefaultExecHandle.java:241) > at > org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:218) > at > org.gradle.process.internal.DefaultExecHandle.failed(DefaultExecHandle.java:369) > at > org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:87) > at > org.gradle.internal.operations.CurrentBuildOperationPreservingRunnable.run(CurrentBuildOperationPreservingRunnable.java:42) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) > at > org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.IllegalStateException: Shutdown in progress > at > java.lang.ApplicationShutdownHooks.remove(ApplicationShutdownHooks.java:82) > at java.lang.Runtime.removeShutdownHook(Runtime.java:239) > at > org.gradle.process.internal.shutdown.ShutdownHooks.removeShutdownHook(ShutdownHooks.java:33) > at > org.gradle.process.internal.DefaultExecHandle.setEndStateInfo(DefaultExecHandle.java:208) > at > org.gradle.process.internal.DefaultExecHandle.aborted(DefaultExecHandle.java:365) > at > org.gradle.process.internal.ExecHandleRunner.completed(ExecHandleRunner.java:108) > at > org.gradle.process.internal.ExecHandleRunner.run(ExecHandleRunner.java:84) > ... 7 more > Also, in > geode-apis-compatible-with-redis/build/test-results/acceptanceTest/binary > output.bin file that Redis container was started but no further information > for its shutdown. No sure if this is normal or not. > ^A<9c>^H^@<8a>^A[info 2021/07/20 16:55:00.011 UTC tid=0xa] > Ryuk started - will monitor and terminate Testcontainers containers on JVM > exit > ^A<9c>^H^@^A > ^A<9c>^H^@Q[info 2021/07/20 16:55:00.012 UTC tid=0xa] Checking > the system... > ^A<9c>^H^@^A > ^A<9c>^H^@p[info 2021/07/20 16:55:00.013 UTC tid=0xa] > â<9c><94>ï¸<8e> Docker server version should be at least 1.6.0 > ^A<9c>^H^@^A > ^A<9c>^H^@~[info 2021/07/20 16:55:00.142 UTC tid=0xa] > â<9c><94>ï¸<8e> Docker environment should have more than 2GB free disk space > ^A<9c>^H^@^A > ^A<9c>^H^@d[info 2021/07/20 16:55:00.161 UTC tid=0xa] Creating > container for image: redis:5.0.6 > ^A<9c>^H^@^A > ^A<9c>^H^@<97>^A[info 2021/07/20 16:55:00.218 UTC tid=0xa] > Starting container with ID: > 3d1530c27f0b4f6e526bfc48b8232708abd3e0de55f188c74e007db30a19d634 > ^A<9c>^H^@^A > ^A<9c>^H^@<9e>^A[info 2021/07/20 16:55:00.658 UTC tid=0xa] > Container redis:5.0.6 is starting: > 3d1530c27f0b4f6e526bfc48b8232708abd3e0de55f188c74e007db30a19d634 > ^A<9c>^H^@^A > ^A<9c>^H^@d[info 2021/07/20 16:55:00.789 UTC tid=0xa] > Container redis:5.0.6 started in PT0.644S > ^A<9c>^H^@^A > ^A<9c>^H^@r[info 2021/07/20 16:55:00.791 UTC tid=0xa] Started > redis container with exposed port 6379 ->
[jira] [Commented] (GEODE-9530) CI Failure: ClassNotFoundException in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
[
https://issues.apache.org/jira/browse/GEODE-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403947#comment-17403947
]
Benjamin P Ross commented on GEODE-9530:
So far trying to recreate this locally has failed, so it could be a
test/pipeline issue. I will try reverting to the commit that originally
reproduced it as well to see if any chances made since effected it.
> CI Failure: ClassNotFoundException in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> -
>
> Key: GEODE-9530
> URL: https://issues.apache.org/jira/browse/GEODE-9530
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.14.0
>
> {noformat}
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> > initializationError FAILED
> java.lang.ClassNotFoundException:
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.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:118)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.0-build.0770/test-results/upgradeTest/1619235491/
>
[jira] [Updated] (GEODE-9539) Remove Radish test SupportedCommandsJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9539: -- Labels: pull-request-available (was: ) > Remove Radish test SupportedCommandsJUnitTest > - > > Key: GEODE-9539 > URL: https://issues.apache.org/jira/browse/GEODE-9539 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > This test doesn't serve any useful purpose anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9499) RedisData does not need an object reference to implement Delta
[ https://issues.apache.org/jira/browse/GEODE-9499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles resolved GEODE-9499. --- Fix Version/s: 1.15.0 Resolution: Fixed Implements static ThreadLocal storage for delta information in RedisData to avoid an object reference per instance. > RedisData does not need an object reference to implement Delta > -- > > Key: GEODE-9499 > URL: https://issues.apache.org/jira/browse/GEODE-9499 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Ray Ingles >Priority: Major > Fix For: 1.15.0 > > > Currently every redis data structure implements the RedisData interface. Part > of that implementation is Delta support. The way it is implemented is by > storing a reference to a DeltaInfo instance in each RedisData. Most of the > time this reference is null but it still takes up 8 bytes (4 if oops are > compressed). It is only non-null while an update is in progress. > What we could do instead is store the reference to the DeltaInfo in a thread > local. That works because we are careful to run each redis command that > modifies a RedisData on the primary. We lock the primary down during the > operation to prevent it from moving. So when it comes time for the primary to > call toDelta on the RedisData instance to distribute it to the secondary, > this call will done on the same thread so our hasDelta and toDelta can just > read the ThreadLocal. This will save us one object reference for every > redis key we store. > Something else we could consider doing is to pass the DeltaInfo as the > callback arg when we do the region put. But this would require change to core > geode to detect that the callback arg is a DeltaInfo and to use it to compute > the delta bytes that are stored on the EntryEventImpl. This is doable and may > even perform better but would require changes to the core. It would probably > be a bit faster than the ThreadLocal solution just because of the extra > latency in setting and reading a ThreadLocal compared to a stack parameter -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9531) CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-9531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anilkumar Gingade updated GEODE-9531:
-
Labels: GeodeOperationAPI blocks-1.14.0 (was: blocks-1.14.0)
> CI Failure: TxCommitMessageBCClientToServerTxPartitionTest fails with
> ForcedDisconnectException
> ---
>
> Key: GEODE-9531
> URL: https://issues.apache.org/jira/browse/GEODE-9531
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Eric Shu
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0
>
> {noformat}
> org.apache.geode.internal.cache.TxCommitMessageBCClientToServerTxPartitionTest
> > test[11] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$55/2050040059.run
> in VM 2 running on Host 1797ac7f43c4 with 5 VMs
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> Caused by:
> org.apache.geode.ForcedDisconnectException: Member isn't
> responding to heartbeat requests
> 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-vm2.log' at line 993
> [fatal 2021/05/25 16:58:13.700 GMT
> tid=1349] Membership service failure: Member isn't responding to heartbeat
> requests
>
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1783)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:725)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1366)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1302)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1077)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:792)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:433)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:72)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:70)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1658)
> at org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1876)
> at org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10)
> at org.jgroups.protocols.TP.handleSingleMessage(TP.java:1789)
> at org.jgroups.protocols.TP.receive(TP.java:1714)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:159)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> at java.lang.Thread.run(Thread.java:748)
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 1041
> [error 2021/05/25 16:58:14.206 GMT
> tid=135] Cache initialization for GemFireCache[id = 664332017; isClosing =
> false; isShutDownAll = false; created = Tue May 25 16:57:54 GMT 2021; server
> = false; copyOnRead = false; lockLease = 120; lockTimeout = 60] failed
> because:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> membership shutdown, caused by org.apache.geode.ForcedDisconnectException:
> Member isn't responding to heartbeat requests
> at
> org.apache.geode.distributed.internal.DistributionImpl.checkCancelled(DistributionImpl.java:313)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:243)
> at
>
[jira] [Commented] (GEODE-9530) CI Failure: ClassNotFoundException in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
[
https://issues.apache.org/jira/browse/GEODE-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403931#comment-17403931
]
Dan Smith commented on GEODE-9530:
--
I suggest we remove this as a 1.14 blocker. This looks like a test and/or
pipeline issue - the test didn't even get a chance to run - it got a
ClassNotFoundException on the test class itself!
I also wonder if this was fixed by later build changes. For example
3c3cbe4721f7b4d2d8f37182e90ae2061bcb742f fixed some dependencies in the build
for upgradeTests - maybe related?
> CI Failure: ClassNotFoundException in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> -
>
> Key: GEODE-9530
> URL: https://issues.apache.org/jira/browse/GEODE-9530
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.14.0
>
> {noformat}
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> > initializationError FAILED
> java.lang.ClassNotFoundException:
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.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:118)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
>
[jira] [Commented] (GEODE-9532) CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer fails with NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403929#comment-17403929
]
Jianxia Chen commented on GEODE-9532:
-
This bug is not easy to reproduce. Based on the analysis with additional
logging, this is more like a test issue. VM2 disconnected and registered a
customized DataSerializer before reconnect. Then VM2 did a put and get on a
persistent replicated region. When the asynchronous disk store were trying to
flush the data to disk on the other two VMs VM0 and VM1, these two VMs were not
aware of the new customized DataSerializer, therefore they throw serialization
exception when serializing the instance of LongWrapper class. It depends on
timing. Most of the time, when the async disk store is flushing, VM0 and VM1
have already got the customized DataSerializer after VM2 reconnects, so there
is no serialization issue and the test passes.
> CI Failure: DiskDistributedNoAckAsyncRegionDUnitTest > testNoDataSerializer
> fails with NotSerializableException
> ---
>
> Key: GEODE-9532
> URL: https://issues.apache.org/jira/browse/GEODE-9532
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Jianxia Chen
>Priority: Major
> Labels: GeodeOperationAPI, blocks-1.14.0
>
> {noformat}
> org.apache.geode.cache30.DiskDistributedNoAckAsyncRegionDUnitTest >
> testNoDataSerializer FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 570
> [fatal 2021/06/15 17:11:03.722 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145]
> Fatal error from asynchronous flusher thread
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2105)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2088)
> at
> org.apache.geode.internal.cache.VMCachedDeserializable.getSerializedValue(VMCachedDeserializable.java:200)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapper(DiskEntry.java:753)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.createValueWrapperFromEntry(DiskEntry.java:807)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:825)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeToDisk(DiskEntry.java:815)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.writeEntryToDisk(DiskEntry.java:1493)
> at
> org.apache.geode.internal.cache.entries.DiskEntry$Helper.doAsyncFlush(DiskEntry.java:1445)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.doAsyncFlush(DiskStoreImpl.java:1765)
> at
> org.apache.geode.internal.cache.DiskStoreImpl$FlusherThread.run(DiskStoreImpl.java:1723)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.io.NotSerializableException:
> org.apache.geode.cache30.MultiVMRegionTestCase$LongWrapper
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:348)
> at
> org.apache.geode.internal.InternalDataSerializer.writeSerializableObject(InternalDataSerializer.java:2186)
> at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2055)
> at org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839)
> at
> org.apache.geode.internal.util.BlobHelper.serializeToBlob(BlobHelper.java:54)
> at
> org.apache.geode.internal.cache.EntryEventImpl.serialize(EntryEventImpl.java:2103)
> ... 11 more
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 594
> [error 2021/06/15 17:11:03.734 GMT DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer> tid=2145] A
> DiskAccessException has occurred while writing to the disk for disk store
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer. The cache will
> be closed.
> org.apache.geode.cache.DiskAccessException: For DiskStore:
> DiskDistributedNoAckAsyncRegionDUnitTest_testNoDataSerializer: Fatal error
> from asynchronous flusher thread, caused by
> org.apache.geode.SerializationException: An IOException was thrown while
> serializing.
[jira] [Created] (GEODE-9539) Remove Radish test SupportedCommandsJUnitTest
Jens Deppe created GEODE-9539: - Summary: Remove Radish test SupportedCommandsJUnitTest Key: GEODE-9539 URL: https://issues.apache.org/jira/browse/GEODE-9539 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe This test doesn't serve any useful purpose anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9539) Remove Radish test SupportedCommandsJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9539: - Assignee: Jens Deppe > Remove Radish test SupportedCommandsJUnitTest > - > > Key: GEODE-9539 > URL: https://issues.apache.org/jira/browse/GEODE-9539 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > > This test doesn't serve any useful purpose anymore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9518) Implement ZUNIONSTORE Command
[ https://issues.apache.org/jira/browse/GEODE-9518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9518: -- Labels: pull-request-available (was: ) > Implement ZUNIONSTORE Command > - > > Key: GEODE-9518 > URL: https://issues.apache.org/jira/browse/GEODE-9518 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: pull-request-available > > Implement the [ZUNIONSTORE|https://redis.io/commands/zunionstore] Command, > with all options, and associated tests. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. The > command has been tested using the redis-cli tool and verified against native > redis. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9530) CI Failure: ClassNotFoundException in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
[
https://issues.apache.org/jira/browse/GEODE-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wayne reassigned GEODE-9530:
Assignee: Benjamin P Ross
> CI Failure: ClassNotFoundException in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> -
>
> Key: GEODE-9530
> URL: https://issues.apache.org/jira/browse/GEODE-9530
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.14.0
>
> {noformat}
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> > initializationError FAILED
> java.lang.ClassNotFoundException:
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.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:118)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.0-build.0770/test-results/upgradeTest/1619235491/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
>
[jira] [Commented] (GEODE-9528) CI Failure: DistributionAdvisorIntegrationTest > verifyMembershipListenerIsRemovedAfterForceDisconnect
[
https://issues.apache.org/jira/browse/GEODE-9528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403901#comment-17403901
]
Alexander Murmann commented on GEODE-9528:
--
[~echobravo] Seeing how many versions this impact, I wonder if this has been in
the product all along or was recently introduced by something that got
backported. Do you know yet? Answering this question might give us an
opportunity to just remove this as a blocker.
> CI Failure: DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect
> --
>
> Key: GEODE-9528
> URL: https://issues.apache.org/jira/browse/GEODE-9528
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.12.5, 1.13.5, 1.14.0
>Reporter: Owen Nichols
>Assignee: Ernest Burghardt
>Priority: Major
> Labels: blocks-1.12.5, blocks-1.13.5, blocks-1.14.0
>
> {noformat}
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest >
> verifyMembershipListenerIsRemovedAfterForceDisconnect FAILED
> org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.internal.DistributionAdvisorIntegrationTest.verifyMembershipListenerIsRemovedAfterForceDisconnect(DistributionAdvisorIntegrationTest.java:57)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9379) Implement ZREVRANGEBYSCORE Command
[ https://issues.apache.org/jira/browse/GEODE-9379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ray Ingles resolved GEODE-9379. --- Fix Version/s: 1.15.0 Resolution: Fixed > Implement ZREVRANGEBYSCORE Command > -- > > Key: GEODE-9379 > URL: https://issues.apache.org/jira/browse/GEODE-9379 > Project: Geode > Issue Type: New Feature > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Ray Ingles >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Implement the [ZREVRANGEBYSCORE|https://redis.io/commands/zrevrangebyscore] > command. > > Acceptance Criteria > The ZREVRANGEBYSCORE command has been implemented along with appropriate unit > tests. > > The command has been added to the AbstractHitsMissesIntegrationTest. > The command has been tested using the redis-cli tool. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9538) NullPointerException in ServerConnection.doNormalMessage()
[
https://issues.apache.org/jira/browse/GEODE-9538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos updated GEODE-9538:
--
Description:
I've hit this issue while executing some chaos testing over a GemFire cluster
using 2 locators and 3 servers; {{SSL}} is enabled and a dummy
{{SecurityManager}} is configured to authenticate and authorize a
pre-configured set of well known users.
There are 3 {{PARTITION_REDUNDANT}} regions configured, one per client, each
with 1 redundant copy. Once the cluster is up and running, 3 clients
continuously execute {{Region.get}} and {{Region.put}} operations on a known
set of keys for its own {{Region}} (created with {{PROXY}} type), and another
process executes the following logic in parallel (pseudocode):
{noformat}
for server in ${servers}
do
# Pause the JVM for 30 seconds to simulate a stop the world GC
kill -STOP server
sleep 30
# Unpause the JVM, wait for member to reconnect and regions to recover
redundancy configured
kill -CONT "${SERVER_PID}"
waitForReconnectcompletedInServerLog
waitForNumBucketsWithoutRedundancyToBeZeroInGfshShowRegionMetrics
done
{noformat}
The test works fine most of the time, but randomly fails due to an unexpected
exception logged within the logs of at least one server. The exception is
always reported from a {{ServerConnection}} thread on the server member that
has just returned to life, as an example:
{noformat}
[info 2021/08/09 11:01:07.430 GMT system-test-gemfire-server-2 tid=0x8d] Configured redundancy of 2 copies has been
restored to /system-test-client-7f6795dfb8-v7hh8-region
[warn 2021/08/09 11:02:19.742 GMT system-test-gemfire-server-2
tid=0x4d] Server connection from
[identity(system-test-client-7f6795dfb8-pc8mv(SpringBasedClientCacheApplication:1:loner):34788:814b8d2a:SpringBasedClientCacheApplication,connection=1;
port=50264] is being terminated because its client timeout of 1 has
expired.
[warn 2021/08/09 11:02:19.744 GMT system-test-gemfire-server-2
tid=0x4d] ClientHealthMonitor: Unregistering
client with member id
identity(system-test-client-7f6795dfb8-pc8mv(SpringBasedClientCacheApplication:1:loner):34788:814b8d2a:SpringBasedClientCacheApplication,connection=1
due to: Unknown reason
[info 2021/08/09 11:02:19.745 GMT system-test-gemfire-server-2 tid=0x1e] received suspect message
from
system-test-gemfire-locator-0(system-test-gemfire-locator-0:1:locator):41000
for system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000:
Member isn't responding to heartbeat requests
[info 2021/08/09 11:02:19.747 GMT system-test-gemfire-server-2 tid=0x1e] Membership received a
request to remove
system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000 from
system-test-gemfire-locator-1(system-test-gemfire-locator-1:1:locator):41000
reason=Member isn't responding to heartbeat requests
[warn 2021/08/09 11:02:19.748 GMT system-test-gemfire-server-2
tid=0x38] Statistics sampling thread detected a wakeup delay of 29965 ms,
indicating a possible resource issue. Check the GC, memory, and CPU statistics.
...
[warn 2021/08/09 11:02:19.854 GMT system-test-gemfire-server-2
tid=0x91] ClientHealthMonitor:
Unregistering client with member id
identity(system-test-client-7f6795dfb8-v7hh8(SpringBasedClientCacheApplication:1:loner):44012:ec3c8d2a:SpringBasedClientCacheApplication,connection=1
due to: The connection has been reset while reading the header
[info 2021/08/09 11:02:19.867 GMT system-test-gemfire-server-2 tid=0x1e] saving cache server
configuration for use with the cluster-configuration service on reconnect
[info 2021/08/09 11:02:19.867 GMT system-test-gemfire-server-2 tid=0x1e] cache server
configuration saved
[fatal 2021/08/09 11:02:19.876 GMT system-test-gemfire-server-2
tid=0xa9] Uncaught exception in
thread Thread[ServerConnection on port 40404 Thread 14,5,main]
java.lang.NullPointerException
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:865)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1022)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1275)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.base/java.lang.Thread.run(Thread.java:829)
{noformat}
The problem itself is really hard to reproduce, we only hit it twice in around
200 runs.
[jira] [Created] (GEODE-9538) NullPointerException in ServerConnection.doNormalMessage()
Juan Ramos created GEODE-9538:
-
Summary: NullPointerException in ServerConnection.doNormalMessage()
Key: GEODE-9538
URL: https://issues.apache.org/jira/browse/GEODE-9538
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Juan Ramos
I've hit this issue while executing some chaos testing over a GemFire cluster
using 2 locators and 3 servers; {{SSL}} is enabled and a dummy
{{SecurityManager}} is configured to authenticate and authorize a
pre-configured set of well known users.
There are 3 {{PARTITION_REDUNDANT}} regions configured, one per client, each
with 1 redundant copy. Once the cluster is up and running, 3 clients
continuously execute {{Region.get}} and {{Region.put}} operations on a known
set of keys for its own {{Region}} (created with {{PROXY}} type), and another
process executes the following logic in parallel (pseudocode):
{noformat}
for server in ${servers}
do
# Pause the JVM for 30 seconds to simulate a stop the world GC
kill -STOP server
sleep 30
# Unpause the JVM, wait for member to reconnect and regions to recover
redundancy configured
kill -CONT "${SERVER_PID}"
waitForReconnectcompletedInServerLog
waitForNumBucketsWithoutRedundancyToBeZeroInGfshShowRegionMetrics
done
{noformat}
The test works fine most of the time, but randomly fails due to an unexpected
exception logged within the logs of at least one server. The exception is
always reported from a {{ServerConnection}} thread on the server member that
has just returned to life, as an example:
{noformat}
[info 2021/08/09 11:01:07.430 GMT system-test-gemfire-server-2 tid=0x8d] Configured redundancy of 2 copies has been
restored to /system-test-client-7f6795dfb8-v7hh8-region
[warn 2021/08/09 11:02:19.742 GMT system-test-gemfire-server-2
tid=0x4d] Server connection from
[identity(system-test-client-7f6795dfb8-pc8mv(SpringBasedClientCacheApplication:1:loner):34788:814b8d2a:SpringBasedClientCacheApplication,connection=1;
port=50264] is being terminated because its client timeout of 1 has
expired.
[warn 2021/08/09 11:02:19.744 GMT system-test-gemfire-server-2
tid=0x4d] ClientHealthMonitor: Unregistering
client with member id
identity(system-test-client-7f6795dfb8-pc8mv(SpringBasedClientCacheApplication:1:loner):34788:814b8d2a:SpringBasedClientCacheApplication,connection=1
due to: Unknown reason
[info 2021/08/09 11:02:19.745 GMT system-test-gemfire-server-2 tid=0x1e] received suspect message
from
system-test-gemfire-locator-0(system-test-gemfire-locator-0:1:locator):41000
for system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000:
Member isn't responding to heartbeat requests
[info 2021/08/09 11:02:19.747 GMT system-test-gemfire-server-2 tid=0x1e] Membership received a
request to remove
system-test-gemfire-server-2(system-test-gemfire-server-2:1):41000 from
system-test-gemfire-locator-1(system-test-gemfire-locator-1:1:locator):41000
reason=Member isn't responding to heartbeat requests
[warn 2021/08/09 11:02:19.748 GMT system-test-gemfire-server-2
tid=0x38] Statistics sampling thread detected a wakeup delay of 29965 ms,
indicating a possible resource issue. Check the GC, memory, and CPU statistics.
...
[warn 2021/08/09 11:02:19.854 GMT system-test-gemfire-server-2
tid=0x91] ClientHealthMonitor:
Unregistering client with member id
identity(system-test-client-7f6795dfb8-v7hh8(SpringBasedClientCacheApplication:1:loner):44012:ec3c8d2a:SpringBasedClientCacheApplication,connection=1
due to: The connection has been reset while reading the header
[info 2021/08/09 11:02:19.867 GMT system-test-gemfire-server-2 tid=0x1e] saving cache server
configuration for use with the cluster-configuration service on reconnect
[info 2021/08/09 11:02:19.867 GMT system-test-gemfire-server-2 tid=0x1e] cache server
configuration saved
[fatal 2021/08/09 11:02:19.876 GMT system-test-gemfire-server-2
tid=0xa9] Uncaught exception in
thread Thread[ServerConnection on port 40404 Thread 14,5,main]
java.lang.NullPointerException
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:865)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1022)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1275)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
