[jira] [Commented] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428281#comment-17428281 ] ASF GitHub Bot commented on GEODE-9591: --- pdxcodemonkey commented on pull request #866: URL: https://github.com/apache/geode-native/pull/866#issuecomment-942397899 @jvarenina Just want to mention here, in case it's important going forward: The test `Apache.Geode.Client.UnitTests.ThinClientFunctionExecutionTests.OnServerHAExecuteFunctionTest` has failed on the Server 2019, VS 2019 release build job in CI (https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop/jobs/build-windows-2019-vs-2019-release/builds/122). It has passed on other Windows jobs (https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop/jobs/build-windows-2016-vs-2017-release/builds/120 , e.g.), but failed first and then passed on retry. This seems at least plausibly related to this PR, so it's worth keeping an eye on. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9677:
Assignee: Xiaojian Zhou
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou updated GEODE-9677:
-
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9534) Add tests to verify peer communication when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9534. Fix Version/s: 1.15.0 Resolution: Fixed > Add tests to verify peer communication when auth expired > > > Key: GEODE-9534 > URL: https://issues.apache.org/jira/browse/GEODE-9534 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > > When a server joins the cluster, it needs to provide credentials, what if we > expire this credential, will peer to peer communication still succeeds? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9540) verify client bulk operations like putAll and getAll and succeed after authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-9540. Fix Version/s: 1.15.0 Resolution: Fixed > 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 >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9540) verify client bulk operations like putAll and getAll and succeed after authentication expires
[ https://issues.apache.org/jira/browse/GEODE-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428313#comment-17428313 ] ASF subversion and git services commented on GEODE-9540: Commit 03ea94bde9a227ac391c0dd5ffc74e20a1156787 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=03ea94b ] GEODE-9534, GEODE-9540: add more tests for peer communication and bulk operations (#6985) * add more tests for durable clients > 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 >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9534) Add tests to verify peer communication when auth expired
[ https://issues.apache.org/jira/browse/GEODE-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428312#comment-17428312 ] ASF subversion and git services commented on GEODE-9534: Commit 03ea94bde9a227ac391c0dd5ffc74e20a1156787 in geode's branch refs/heads/develop from Jinmei Liao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=03ea94b ] GEODE-9534, GEODE-9540: add more tests for peer communication and bulk operations (#6985) * add more tests for durable clients > Add tests to verify peer communication when auth expired > > > Key: GEODE-9534 > URL: https://issues.apache.org/jira/browse/GEODE-9534 > Project: Geode > Issue Type: Sub-task >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeOperationAPI, pull-request-available, security > Fix For: 1.15.0 > > > When a server joins the cluster, it needs to provide credentials, what if we > expire this credential, will peer to peer communication still succeeds? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9731) Fix flaky PubSubIntegrationTest
Jens Deppe created GEODE-9731: - Summary: Fix flaky PubSubIntegrationTest Key: GEODE-9731 URL: https://issues.apache.org/jira/browse/GEODE-9731 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9731) Fix flaky PubSubIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe reassigned GEODE-9731: - Assignee: Jens Deppe > Fix flaky PubSubIntegrationTest > --- > > Key: GEODE-9731 > URL: https://issues.apache.org/jira/browse/GEODE-9731 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9731) Fix flaky PubSubIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9731: -- Labels: pull-request-available (was: ) > Fix flaky PubSubIntegrationTest > --- > > Key: GEODE-9731 > URL: https://issues.apache.org/jira/browse/GEODE-9731 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9731) Fix flaky PubSubIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428321#comment-17428321
]
Jens Deppe commented on GEODE-9731:
---
Saw this test fail during a PR run with:
{noformat}
PubSubIntegrationTest > testPatternAndRegularSubscribe FAILED
14:31:47java.lang.AssertionError:
14:31:47Expecting actual:
14:31:47 []
14:31:47to contain exactly (and in same order):
14:31:47 ["hello"]
14:31:47but could not find the following elements:
14:31:47 ["hello"]
14:31:47at
org.apache.geode.redis.internal.executor.pubsub.AbstractPubSubIntegrationTest.testPatternAndRegularSubscribe(AbstractPubSubIntegrationTest.java:741)
14:31:47at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
14:31:47at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
14:31:47at
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
14:31:47at java.lang.reflect.Method.invoke(Method.java:566)
14:31:47at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
14:31:47at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
14:31:47at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
14:31:47at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
14:31:47at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
14:31:47at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
14:31:47at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
14:31:47at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
14:31:47at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
14:31:47at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
14:31:47at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
14:31:47at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
14:31:47at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
14:31:47at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
14:31:47at
org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
14:31:47at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
14:31:47at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
14:31:47at
org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
14:31:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
14:31:47at
org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
14:31:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
14:31:47at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
14:31:47at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
14:31:47at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
14:31:47at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
14:31:47at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
14:31:47at java.util.Iterator.forEachRemaining(Iterator.java:133)
14:31:47at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
14:31:47at
java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
14:31:47at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
14:31:47at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
14:31:47at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
14:31:47at
java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
14:31:47at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
14:31:47at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
14:31:47at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
14:31:47at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
14:31:47at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
14:31:47at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
14:31:47at
org.junit.platform.launcher.cor
[jira] [Updated] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9677:
--
Labels: GeodeOperationAPI needsTriage pull-request-available (was:
GeodeOperationAPI needsTriage)
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428330#comment-17428330
]
ASF subversion and git services commented on GEODE-9677:
Commit 5f76e5454715056350a471e03031354c0459ba9f in geode's branch
refs/heads/feature/GEODE-9677 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5f76e54 ]
GEODE-9677: After provider sends ImageReply, requester could finish earlier
than provider
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9713) DistributedExecutorServiceRule should have parameter to specify threadCount
[ https://issues.apache.org/jira/browse/GEODE-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428333#comment-17428333 ] ASF subversion and git services commented on GEODE-9713: Commit 269bda1700609f4924251cd22dbde201339890b2 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=269bda1 ] GEODE-9713: Support thread count in ExecutorService rules Restores thread count support to ExecutorServiceRule, and adds it to DistributedExecutorServiceRule. > DistributedExecutorServiceRule should have parameter to specify threadCount > --- > > Key: GEODE-9713 > URL: https://issues.apache.org/jira/browse/GEODE-9713 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > DistributedExecutorServiceRule should have parameter to specify threadCount > in addition to vmCount. ExecutorServiceRule has a parameter to specify > threadCount so it's just a matter of propagating it to the super constructor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9713) DistributedExecutorServiceRule should have parameter to specify threadCount
[ https://issues.apache.org/jira/browse/GEODE-9713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428334#comment-17428334 ] ASF subversion and git services commented on GEODE-9713: Commit 8c1fb0b98ab7231f420c23bca54d3b4be31f0a32 in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8c1fb0b ] GEODE-9713: Simplify DistributedExecutorServiceRuleLimitedThreadCountTest > DistributedExecutorServiceRule should have parameter to specify threadCount > --- > > Key: GEODE-9713 > URL: https://issues.apache.org/jira/browse/GEODE-9713 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > DistributedExecutorServiceRule should have parameter to specify threadCount > in addition to vmCount. ExecutorServiceRule has a parameter to specify > threadCount so it's just a matter of propagating it to the super constructor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428336#comment-17428336
]
Xiaojian Zhou commented on GEODE-9677:
--
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428336#comment-17428336
]
Xiaojian Zhou edited comment on GEODE-9677 at 10/13/21, 4:39 PM:
-
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
I have a fix.
was (Author: zhouxj):
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9038) CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails with suspect strings
[ https://issues.apache.org/jira/browse/GEODE-9038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428338#comment-17428338 ] ASF subversion and git services commented on GEODE-9038: Commit 22c21fbc117af301c84f7d5f213e64508f34a44c in geode's branch refs/heads/develop from Kirk Lund [ https://gitbox.apache.org/repos/asf?p=geode.git;h=22c21fb ] GEODE-9038: Ignore AlertingIOException in ShutdownAllDUnitTest Add ignored exception AlertingIOException to testShutdownAllWithMembersWaiting. > CI Failure: ShutdownAllDUnitTest > testShutdownAllWithMembersWaiting fails > with suspect strings > --- > > Key: GEODE-9038 > URL: https://issues.apache.org/jira/browse/GEODE-9038 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: John Hutchison >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/78 > org.apache.geode.internal.cache.partitioned.ShutdownAllDUnitTest > > testShutdownAllWithMembersWaiting 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 1246 > [fatal 2021/03/15 19:27:44.311 GMT > tid=1461] While pushing message unexpected exception during data cleanup" level WARNING> to recipients: > <172.17.0.7(179):41003> > org.apache.geode.alerting.internal.spi.AlertingIOException: > java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:884) > at > org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:464) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:280) > at > org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187) > at > org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:523) > at > org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346) > at > org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2053) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1981) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2018) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$null$0(ClusterAlertMessaging.java:103) > at > org.apache.geode.alerting.internal.spi.AlertingAction.execute(AlertingAction.java:34) > at > org.apache.geode.alerting.internal.ClusterAlertMessaging.lambda$sendAlert$1(ClusterAlertMessaging.java:81) > at > java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) > 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:834) > Caused by: java.io.IOException: Cannot form connection to alert listener > 172.17.0.7(179):41003 > at > org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:406) > at > org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:574) > at > org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:803) > ... 18 more -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9660) ConcurrentLoopingThreads should not run action in case of thread exceptions
[ https://issues.apache.org/jira/browse/GEODE-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9660: -- Labels: pull-request-available (was: ) > ConcurrentLoopingThreads should not run action in case of thread exceptions > --- > > Key: GEODE-9660 > URL: https://issues.apache.org/jira/browse/GEODE-9660 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > This test class uses CyclicBarriers to implement an action that is performed > at the end of every thread iteration. In the case where one of the threads > produces an exception, the action is still performed. The semantics of this > are different to CyclicBarriers and should really be the same. > Also write some tests for this class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9668) AbstractHitsMissesIntegrationTest.testMsetnx is Failing
[ https://issues.apache.org/jira/browse/GEODE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9668. Fix Version/s: 1.15.0 Resolution: Fixed > AbstractHitsMissesIntegrationTest.testMsetnx is Failing > --- > > Key: GEODE-9668 > URL: https://issues.apache.org/jira/browse/GEODE-9668 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The AbstractHitsMissesIntegrationTest.testMsetnx test is currently failing. > This test is annotated with @Ignore which we would like to remove. The test > is asserting that stats are not updated but they are being updated and > therefore, the tests is failing. > > +Acceptance Criteria+ > The AbstractHitsMissesIntegrationTest.testMsetnx test is passing and the > @Ignore annotation has been removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9668) AbstractHitsMissesIntegrationTest.testMsetnx is Failing
[ https://issues.apache.org/jira/browse/GEODE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428356#comment-17428356 ] ASF subversion and git services commented on GEODE-9668: Commit 220bc2d957dfd95aebd4e52beda0cb9d2e62c124 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=220bc2d ] GEODE-9668: Enable ignored HitsMissesIntegrationTest (#6987) - Un-ignore testMsetnx() - Remove testPassiveExpiration as it was testing that keys were expired, not just that we were updating stats for the expire command - Move testMset() and testMsetnx() from unsupported commands section - Modify key names to be consistent and use hashtags - Refactor to remove unnecessary helper methods - Introduce multi-key helper methods Authored-by: Donal Evans > AbstractHitsMissesIntegrationTest.testMsetnx is Failing > --- > > Key: GEODE-9668 > URL: https://issues.apache.org/jira/browse/GEODE-9668 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The AbstractHitsMissesIntegrationTest.testMsetnx test is currently failing. > This test is annotated with @Ignore which we would like to remove. The test > is asserting that stats are not updated but they are being updated and > therefore, the tests is failing. > > +Acceptance Criteria+ > The AbstractHitsMissesIntegrationTest.testMsetnx test is passing and the > @Ignore annotation has been removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9668) AbstractHitsMissesIntegrationTest.testMsetnx is Failing
[ https://issues.apache.org/jira/browse/GEODE-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9668: --- Affects Version/s: 1.15.0 > AbstractHitsMissesIntegrationTest.testMsetnx is Failing > --- > > Key: GEODE-9668 > URL: https://issues.apache.org/jira/browse/GEODE-9668 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The AbstractHitsMissesIntegrationTest.testMsetnx test is currently failing. > This test is annotated with @Ignore which we would like to remove. The test > is asserting that stats are not updated but they are being updated and > therefore, the tests is failing. > > +Acceptance Criteria+ > The AbstractHitsMissesIntegrationTest.testMsetnx test is passing and the > @Ignore annotation has been removed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428358#comment-17428358 ] Alexander Murmann commented on GEODE-9718: -- [~mkevo] Hi Mario! What version did you encounter this on? Did this happen on an already released version or on develop? > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > > Mail discussion: [Region is not created on one of the > servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9633) Region and gateway receiver init order may cause a hang
[
https://issues.apache.org/jira/browse/GEODE-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428359#comment-17428359
]
Alexander Murmann commented on GEODE-9633:
--
Hi [~alberto.bustamante.reyes]! Thanks for digging this up! What version did
you encounter this on? Did this happen on an already released version or on
develop?
> Region and gateway receiver init order may cause a hang
> ---
>
> Key: GEODE-9633
> URL: https://issues.apache.org/jira/browse/GEODE-9633
> Project: Geode
> Issue Type: Bug
>Reporter: Alberto Bustamante Reyes
>Priority: Major
>
> This ticket has been created as suggested on [the dev
> list|https://markmail.org/thread/qq32z5hducjoqndz].
> -
> I have been analyzing an issue that occurs in the following scenario:
> 1) I start two Geode clusters (cluster1 & cluster2) with one locator and two
> servers each.
> Both clusters host a partitioned region called "testregion", which is
> replicated
> using a parallel gateway sender and a gateway receiver.
> ( These are [the gfsh
> files|https://gist.github.com/alb3rtobr/e230623255632937fa68265f31e97f3a] I
> have been using for creating the clusters)
> 2) I run a client connected to cluster2 performing operations on testregion.
> 3) cluster1 is stopped and all persistent data is deleted. And then, I create
> cluster1 again.
> 4) At this point, the command to create "testregion" get stuck.
> After checking the thread stack and the code, I found that the problem is the
> following.
> This thread is trapped on an infinite loop waiting for a bucket primary
> election
> at "PartitionedRegion.waitForNoStorageOrPrimary":
> {code}
> "Function Execution Processor4" tid=0x55
> java.lang.Thread.State: TIMED_WAITING
> at java.base@11.0.11/java.lang.Object.wait(Native Method)
> - waiting on org.apache.geode.internal.cache.BucketAdvisor@28be7ae0
> at
> app//org.apache.geode.internal.cache.BucketAdvisor.waitForPrimaryMember(BucketAdvisor.java:1433)
> at
> app//org.apache.geode.internal.cache.BucketAdvisor.waitForNewPrimary(BucketAdvisor.java:825)
> at
> app//org.apache.geode.internal.cache.BucketAdvisor.getPrimary(BucketAdvisor.java:794)
> at
> app//org.apache.geode.internal.cache.partitioned.RegionAdvisor.getPrimaryMemberForBucket(RegionAdvisor.java:1032)
> at
> app//org.apache.geode.internal.cache.PartitionedRegion.getBucketPrimary(PartitionedRegion.java:9081)
> at
> app//org.apache.geode.internal.cache.PartitionedRegion.waitForNoStorageOrPrimary(PartitionedRegion.java:3249)
> at
> app//org.apache.geode.internal.cache.PartitionedRegion.getNodeForBucketWrite(PartitionedRegion.java:3234)
> at
> app//org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10110)
> at
> app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:564)
> at
> app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:443)
> at
> app//org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderEventProcessor.java:195)
> at
> app//org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ConcurrentParallelGatewaySenderQueue.java:183)
> at
> app//org.apache.geode.internal.cache.PartitionedRegion.postCreateRegion(PartitionedRegion.java:1177)
> at
> app//org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3050)
> at
> app//org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2910)
> at
> app//org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2894)
> at
> app//org.apache.geode.cache.RegionFactory.create(RegionFactory.java:773)
> {code}
> After creating testregion, the sender queue partitioned region is created.
> While
> that region buckets are recovered the command is trapped on an infinite loop
> waiting for a primary bucket election at
> PartitionedRegion.waitForNoStorageOrPrimary.
> This seems to be a known issue because in
> PartitionedRegion.getNodeForBucketWrite, there is the following command before
> calling waitForNoStorageOrPrimary (and the command has been there since
> Geode's
> first commit!) :
> {code}
> // Possible race with loss of redundancy at this point.
> // This loop can possibly create a soft hang if no primary is ever
> selected.
> // This is preferable to returning null since it will prevent obtaining
> the
[jira] [Commented] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428361#comment-17428361
]
Alexander Murmann commented on GEODE-9632:
--
Hi [~mkevo]! Thanks for reporting this! Do you know what versions this affects?
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit in the query is, it will overwrite it. So there should
> be some changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
[
https://issues.apache.org/jira/browse/GEODE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428370#comment-17428370
]
ASF subversion and git services commented on GEODE-9666:
Commit b39958fafa8690bb978710018a6ecf2bc56244f3 in geode's branch
refs/heads/develop from Aaron Lindsey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b39958f ]
GEODE-9666: Avoid caching InetSocketAddress (#6938)
The changes for GEODE-9139 changed the behavior of
org.apache.geode.distributed.internal.tcpserver.HostAndPort to
permanently cache the internal InetSocketAddress once it has tried one
time to resolve the address. This undoes part of the fix introduced by
GEODE-7808, in which HostAndPort was created as a way to hold an
unresolved hostname.
The issue is that the cached InetSocketAddress may contain a stale or
unresolved address which will be returned by getSocketInetAddress for
the lifetime of the HostAndPort/InetSocketWrapper object. This prevents
the address from being resolved correctly after changes in DNS records.
(Such changes are common in cloud environments.)
This commit removes the cached internal InetSocketAddress from
InetSocketWrapper so that getSocketInetAddress will try to resolve the
address each time it is called with an unresolved address.
> Client throws NoAvailableLocatorsException after locators change IP addresses
> -
>
> Key: GEODE-9666
> URL: https://issues.apache.org/jira/browse/GEODE-9666
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> We have a test for Geode on Kubernetes which:
> * Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
> * Deploys 5 Spring boot client Pods which continually do PUTs and GETs
> * Triggers a rolling restart of the locator Pods
> ** The rolling restart operation restarts one locator at a time, waiting for
> each restarted locator to become fully online before restarting the next
> locator
> * Stops the client operations and validates there were no exceptions thrown
> in the clients.
> Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
> clients:
> {code:none}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
>
> system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
> at
> org.apache.geode.kubernetes.cl
[jira] [Commented] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428371#comment-17428371
]
ASF subversion and git services commented on GEODE-9139:
Commit b39958fafa8690bb978710018a6ecf2bc56244f3 in geode's branch
refs/heads/develop from Aaron Lindsey
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=b39958f ]
GEODE-9666: Avoid caching InetSocketAddress (#6938)
The changes for GEODE-9139 changed the behavior of
org.apache.geode.distributed.internal.tcpserver.HostAndPort to
permanently cache the internal InetSocketAddress once it has tried one
time to resolve the address. This undoes part of the fix introduced by
GEODE-7808, in which HostAndPort was created as a way to hold an
unresolved hostname.
The issue is that the cached InetSocketAddress may contain a stale or
unresolved address which will be returned by getSocketInetAddress for
the lifetime of the HostAndPort/InetSocketWrapper object. This prevents
the address from being resolved correctly after changes in DNS records.
(Such changes are common in cloud environments.)
This commit removes the cached internal InetSocketAddress from
InetSocketWrapper so that getSocketInetAddress will try to resolve the
address each time it is called with an unresolved address.
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Kamilla Aslami
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7808) standardize on use of LocatorAddress/HostAddress for connection formation
[ https://issues.apache.org/jira/browse/GEODE-7808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428372#comment-17428372 ] ASF subversion and git services commented on GEODE-7808: Commit b39958fafa8690bb978710018a6ecf2bc56244f3 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b39958f ] GEODE-9666: Avoid caching InetSocketAddress (#6938) The changes for GEODE-9139 changed the behavior of org.apache.geode.distributed.internal.tcpserver.HostAndPort to permanently cache the internal InetSocketAddress once it has tried one time to resolve the address. This undoes part of the fix introduced by GEODE-7808, in which HostAndPort was created as a way to hold an unresolved hostname. The issue is that the cached InetSocketAddress may contain a stale or unresolved address which will be returned by getSocketInetAddress for the lifetime of the HostAndPort/InetSocketWrapper object. This prevents the address from being resolved correctly after changes in DNS records. (Such changes are common in cloud environments.) This commit removes the cached internal InetSocketAddress from InetSocketWrapper so that getSocketInetAddress will try to resolve the address each time it is called with an unresolved address. > standardize on use of LocatorAddress/HostAddress for connection formation > - > > Key: GEODE-7808 > URL: https://issues.apache.org/jira/browse/GEODE-7808 > Project: Geode > Issue Type: Improvement > Components: membership, messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.13.0 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > We currently use InetAddress and InetSocketAddress in many places to identify > locators, servers and peers. Some work has been done in the past couple of > years to reduce the use of these in order to accommodate changes in IP > addresses due to various causes. The class LocatorAddress was created to > help with this and it is able to hold a host name without resolving it until > that resolution is needed to form a tcp/ip connection. > These days we are seeing more and more movement into cloud computing and the > need to accommodate IP address changes is becoming a bigger issue. To that > end we would like to change our primary client/server and WAN communication > interfaces to stop taking InetAddresses and InetSocketAddresses as arguments > and, instead, take something like a LocatorAddress that can hold an > unresolved hostname that our communication implementations will resolve when > needed. > To that end we should also remove the hostname->inetaddress cache in > SocketCreator and rely on the operating system's DNS cache. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9731) Fix flaky PubSubIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9731: -- Affects Version/s: 1.15.0 > Fix flaky PubSubIntegrationTest > --- > > Key: GEODE-9731 > URL: https://issues.apache.org/jira/browse/GEODE-9731 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9660) ConcurrentLoopingThreads should not run action in case of thread exceptions
[ https://issues.apache.org/jira/browse/GEODE-9660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9660: -- Affects Version/s: 1.15.0 > ConcurrentLoopingThreads should not run action in case of thread exceptions > --- > > Key: GEODE-9660 > URL: https://issues.apache.org/jira/browse/GEODE-9660 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > This test class uses CyclicBarriers to implement an action that is performed > at the end of every thread iteration. In the case where one of the threads > produces an exception, the action is still performed. The semantics of this > are different to CyclicBarriers and should really be the same. > Also write some tests for this class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-9627:
--
Affects Version/s: 1.15.0
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
> This work is related to GEODE-9618
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9676) Limit Radish RESP bulk input sizes for unauthenticated connections
[ https://issues.apache.org/jira/browse/GEODE-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-9676: -- Affects Version/s: 1.15.0 > Limit Radish RESP bulk input sizes for unauthenticated connections > -- > > Key: GEODE-9676 > URL: https://issues.apache.org/jira/browse/GEODE-9676 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Priority: Major > Labels: redis > > Redis recently implemented a response to a CVE which allows for > unauthenticated users to craft RESP requests which consume a lot of memory. > Our implementation suffers from the same problem. > For example, a command input starting with `*` would result in the > JVM trying to allocate an array of size `MAX_INT`. > We need to be able to provide the same safeguards as Redis does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9666) Client throws NoAvailableLocatorsException after locators change IP addresses
[
https://issues.apache.org/jira/browse/GEODE-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aaron Lindsey resolved GEODE-9666.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> Client throws NoAvailableLocatorsException after locators change IP addresses
> -
>
> Key: GEODE-9666
> URL: https://issues.apache.org/jira/browse/GEODE-9666
> Project: Geode
> Issue Type: Bug
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> We have a test for Geode on Kubernetes which:
> * Deploys a Geode cluster consisting of 2 locator Pods, 3 server Pods
> * Deploys 5 Spring boot client Pods which continually do PUTs and GETs
> * Triggers a rolling restart of the locator Pods
> ** The rolling restart operation restarts one locator at a time, waiting for
> each restarted locator to become fully online before restarting the next
> locator
> * Stops the client operations and validates there were no exceptions thrown
> in the clients.
> Occasionally, we see {{NoAvailableLocatorsException}} thrown on one of the
> clients:
> {code:none}
> org.apache.geode.cache.client.NoAvailableLocatorsException: Unable to connect
> to any locators in the list
> [system-test-gemfire-locator-0.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334,
>
> system-test-gemfire-locator-1.system-test-gemfire-locator.gemfire-system-test-3f1ecc74-b1ea-4288-b4d1-594bbb8364ab.svc.cluster.local:10334]
> at
> org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.findServer(AutoConnectionSourceImpl.java:174)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:198)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:196)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:276)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:136)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:92)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:114)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2802)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1469)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1442)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:197)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1379)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1318)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1303)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:439)
> at
> org.apache.geode.kubernetes.client.service.AsyncOperationService.evaluate(AsyncOperationService.java:282)
> at
> org.apache.geode.kubernetes.client.api.Controller.evaluateRegion(Controller.java:88)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:197)
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:141)
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:106)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:894)
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.h
[jira] [Commented] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428381#comment-17428381 ] ASF subversion and git services commented on GEODE-9625: Commit 3a7b7bae47b454b8c9f47f80be3a0a90a4877343 in geode's branch refs/heads/support/1.14 from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3a7b7ba ] GEODE-9625: Only serialize transaction metadata when grouping enabled. (#6984) (cherry picked from commit ab651eba9558752fe1336919e462350f4581a22a) > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: blocks-1.14.1, pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett resolved GEODE-9625. -- Resolution: Fixed > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: blocks-1.14.1, pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-9625: - Labels: pull-request-available (was: blocks-1.14.1 pull-request-available) > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9625) GatwaySenderEventImpl always serializes metadata necessary only for transaction grouping
[ https://issues.apache.org/jira/browse/GEODE-9625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob Barrett updated GEODE-9625: - Fix Version/s: 1.14.1 > GatwaySenderEventImpl always serializes metadata necessary only for > transaction grouping > > > Key: GEODE-9625 > URL: https://issues.apache.org/jira/browse/GEODE-9625 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0, 1.15.0 >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: blocks-1.14.1, pull-request-available > Fix For: 1.14.1, 1.15.0 > > > Recent additions for transaction grouping in WAN caused > GatewaySenderEventImpl to serialize transaction ID and last transaction flags > for every event regardless of the configuration of the transaction grouping > option. This results in both WAN and AEQ queues to replication unnecessary > data. Transaction ID also includes the member ID which is a large-sh object. > The overhead should be removed from queues that don't need that metadata. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
[
https://issues.apache.org/jira/browse/GEODE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428391#comment-17428391
]
ASF subversion and git services commented on GEODE-9714:
Commit 905d08a4f72de97c37f4cc67cda0697b39041029 in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=905d08a ]
GEODE-9714: Add Shiro packages to sanctioned serializables
Adds all Shiro subpackages that contain exceptions to the list of
sanctioned serializables.
> CI: QueryConfigurationServiceConstraintsDistributedTest failed with
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> ---
>
> Key: GEODE-9714
> URL: https://issues.apache.org/jira/browse/GEODE-9714
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.0, 1.13.0, 1.14.0, 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
> {code:java}
> QueryConfigurationServiceConstraintsDistributedTest > [10]
> indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
> 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-vm2.log' at line 357
> [fatal 2021/10/09 19:11:41.270 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.StoppedSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
> at
> org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at
> org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
> at
> org.apache.geode.internal.cache.LocalRegion.serverDestroy(LocalRegion.java:3095)
> at
> org.apach
[jira] [Commented] (GEODE-9689) MultiUserAPIDUnitTest "Failed to find the authenticated user"
[
https://issues.apache.org/jira/browse/GEODE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428393#comment-17428393
]
Dale Emery commented on GEODE-9689:
---
Similar failure and stack trace in a different test:
https://concourse.apachegeode-ci.info/builds/88799#L60fea469:585:656
> MultiUserAPIDUnitTest "Failed to find the authenticated user"
> -
>
> Key: GEODE-9689
> URL: https://issues.apache.org/jira/browse/GEODE-9689
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Priority: Major
> Labels: needsTriage
>
> In a PR [precheckin run for an unrelated
> change|https://concourse.apachegeode-ci.info/builds/86024#L60fbd583:610],
> {{MultiUserAPIDUnitTest}} failed with this exception:
> {noformat}
> MultiUserAPIDUnitTest > jsonFormatterOnTheClientWithSingleUser FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-3da43d93-7b04-56a2-b164-c14df052c421(402921:loner):57640:8f03df57:
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:559)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:623)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:500)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3048)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3163)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5612)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5590)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5048)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1646)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1633)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> at
> org.apache.geode.security.MultiUserAPIDUnitTest.jsonFormatterOnTheClientWithSingleUser(MultiUserAPIDUnitTest.java:219)
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed to
> find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put70.cmdExecute(Put70.java:243)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
> 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:1051)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> 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.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9689) MultiUserAPIDUnitTest "Failed to find the authenticated user"
[
https://issues.apache.org/jira/browse/GEODE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery updated GEODE-9689:
--
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> MultiUserAPIDUnitTest "Failed to find the authenticated user"
> -
>
> Key: GEODE-9689
> URL: https://issues.apache.org/jira/browse/GEODE-9689
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> In a PR [precheckin run for an unrelated
> change|https://concourse.apachegeode-ci.info/builds/86024#L60fbd583:610],
> {{MultiUserAPIDUnitTest}} failed with this exception:
> {noformat}
> MultiUserAPIDUnitTest > jsonFormatterOnTheClientWithSingleUser FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-3da43d93-7b04-56a2-b164-c14df052c421(402921:loner):57640:8f03df57:
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:559)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:623)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:500)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3048)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3163)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5612)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5590)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5048)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1646)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1633)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> at
> org.apache.geode.security.MultiUserAPIDUnitTest.jsonFormatterOnTheClientWithSingleUser(MultiUserAPIDUnitTest.java:219)
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed to
> find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put70.cmdExecute(Put70.java:243)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
> 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:1051)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> 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.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-9635: Fix Version/s: 1.15.0 > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac resolved GEODE-9635. - Resolution: Fixed > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9635) After gw sender is started with --clean queue, new received events are discarded
[ https://issues.apache.org/jira/browse/GEODE-9635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428402#comment-17428402 ] ASF subversion and git services commented on GEODE-9635: Commit 615f180f5dfdde52afab47096bc1e30e0146467e in geode's branch refs/heads/develop from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=615f180 ] GEODE-9635: wait for bucket initialization, after clean queue (#6916) * GEODE-9635: wait for bucket initialization, after clean queue * GEODE-9635: added test case to reproduce fault * GEODE-9635: added UT > After gw sender is started with --clean queue, new received events are > discarded > > > Key: GEODE-9635 > URL: https://issues.apache.org/jira/browse/GEODE-9635 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > After GW senders are startde with --clean queue option, new received events > are discarded until queue region buckets are initialized. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9688) .Net core builds should be x64
[ https://issues.apache.org/jira/browse/GEODE-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428406#comment-17428406 ] ASF GitHub Bot commented on GEODE-9688: --- pdxcodemonkey merged pull request #878: URL: https://github.com/apache/geode-native/pull/878 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > .Net core builds should be x64 > -- > > Key: GEODE-9688 > URL: https://issues.apache.org/jira/browse/GEODE-9688 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: needsTriage, pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428408#comment-17428408 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell opened a new pull request #881: URL: https://github.com/apache/geode-native/pull/881 This switches the NetCore test framework to Xunit fixtures. A separate fixture is used for each of the test suites (i.e., netcore-integration-test and netcore-session-integration-test. It also just creates an authRegion not separate cluster for the netcore auth tests. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9639) Make native client compatible with C++20
[ https://issues.apache.org/jira/browse/GEODE-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428411#comment-17428411 ] ASF GitHub Bot commented on GEODE-9639: --- pivotal-jbarrett commented on pull request #874: URL: https://github.com/apache/geode-native/pull/874#issuecomment-941736026 > * std::not1 (TcrMessage.cpp) Replace that whole `std::string::erase` statement with [`boost::algorithm::trim_left`](https://www.boost.org/doc/libs/1_77_0/doc/html/boost/algorithm/trim_left.html). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Make native client compatible with C++20 > > > Key: GEODE-9639 > URL: https://issues.apache.org/jira/browse/GEODE-9639 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Labels: pull-request-available > > There are standard library components that were removed in C++20, making our > library incompatible. Luckily, our use of deleted components are minimal and > replaceable without breaking API backward compatibility, but it will disrupt > ABI compatibility. > > The outcome needs to be tested against MSVC2017/v141 and MSVC2019/v142, > including examples. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9719) Switch .NET Core Tests to Xunit Fixtures
[ https://issues.apache.org/jira/browse/GEODE-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428416#comment-17428416 ] ASF GitHub Bot commented on GEODE-9719: --- mmartell commented on pull request #881: URL: https://github.com/apache/geode-native/pull/881#issuecomment-941283771 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Switch .NET Core Tests to Xunit Fixtures > > > Key: GEODE-9719 > URL: https://issues.apache.org/jira/browse/GEODE-9719 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > > The programmatic cluster support brought in by > [GEODE-9600|http://example.com] currently starts and stops the geode cluster > for each test. This ticket is to switch the tests to an Xunit fixture model > wherein all tests for netcore-lib will be run against a single cluster > start/stop, and similarly for netcore-session. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
Kirk Lund created GEODE-9732:
Summary: CI Failure: ExpireNativeRedisAcceptanceTest fails with
JedisClusterException: CLUSTERDOWN The cluster is down
Key: GEODE-9732
URL: https://issues.apache.org/jira/browse/GEODE-9732
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Kirk Lund
Looks like every test in the class fails when whatever caused this happens.
{noformat}
ExpireNativeRedisAcceptanceTest >
usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
cluster is down
at redis.clients.jedis.Protocol.processError(Protocol.java:125)
at redis.clients.jedis.Protocol.process(Protocol.java:169)
at redis.clients.jedis.Protocol.read(Protocol.java:223)
at
redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
at redis.clients.jedis.Jedis.hset(Jedis.java:831)
at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
at
redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
at
redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
at
org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at
org.junit.vintag
[jira] [Updated] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9732:
-
Labels: needsTriage (was: )
> CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException:
> CLUSTERDOWN The cluster is down
> -
>
> Key: GEODE-9732
> URL: https://issues.apache.org/jira/browse/GEODE-9732
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> Looks like every test in the class fails when whatever caused this happens.
> {noformat}
> ExpireNativeRedisAcceptanceTest >
> usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.hset(Jedis.java:831)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
> at
> org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
> 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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.copyInto(Abs
[jira] [Commented] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428422#comment-17428422
]
Geode Integration commented on GEODE-9732:
--
Seen in [acceptance-test-openjdk8
#264|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/264]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0571/test-results/acceptanceTest/1634106441/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0571/test-artifacts/1634106441/acceptancetestfiles-openjdk8-1.15.0-build.0571.tgz].
> CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException:
> CLUSTERDOWN The cluster is down
> -
>
> Key: GEODE-9732
> URL: https://issues.apache.org/jira/browse/GEODE-9732
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> Looks like every test in the class fails when whatever caused this happens.
> {noformat}
> ExpireNativeRedisAcceptanceTest >
> usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.hset(Jedis.java:831)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
> at
> org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
> 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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:
[jira] [Updated] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9732:
-
Affects Version/s: 1.15.0
> CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException:
> CLUSTERDOWN The cluster is down
> -
>
> Key: GEODE-9732
> URL: https://issues.apache.org/jira/browse/GEODE-9732
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> Looks like every test in the class fails when whatever caused this happens.
> {noformat}
> ExpireNativeRedisAcceptanceTest >
> usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.hset(Jedis.java:831)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
> at
> org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
> 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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline.c
[jira] [Commented] (GEODE-9600) Add Programmatic Cluster Support to NetCore.Test
[ https://issues.apache.org/jira/browse/GEODE-9600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428425#comment-17428425 ] ASF GitHub Bot commented on GEODE-9600: --- mmartell merged pull request #880: URL: https://github.com/apache/geode-native/pull/880 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Programmatic Cluster Support to NetCore.Test > > > Key: GEODE-9600 > URL: https://issues.apache.org/jira/browse/GEODE-9600 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Assignee: Michael Martell >Priority: Major > Labels: pull-request-available > > We just need to bring a few files over from the new clicache test framework > (clicache/integration-test2): > * Cluster.cs > * Gfsh.cs > * GfshExecute.cs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-9732:
-
Description:
Looks like every test in the class fails when whatever caused this happens.
{noformat}
ExpireNativeRedisAcceptanceTest >
usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
cluster is down
at redis.clients.jedis.Protocol.processError(Protocol.java:125)
at redis.clients.jedis.Protocol.process(Protocol.java:169)
at redis.clients.jedis.Protocol.read(Protocol.java:223)
at
redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
at redis.clients.jedis.Jedis.hset(Jedis.java:831)
at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
at
redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
at
redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
at
org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
at
org.junit.platform.launcher.core.En
[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&focusedCommentId=17428440#comment-17428440
]
Geode Integration commented on GEODE-9531:
--
Seen on support/1.13 in [upgrade-test-openjdk11
#62|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/62]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0606/test-results/upgradeTest/1634119201/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0606/test-artifacts/1634119201/upgradetestfiles-openjdk11-1.13.5-build.0606.tgz].
> 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
[jira] [Commented] (GEODE-9591) Native client re-execute function even Function.isHA() is set to false and redundancy in not used on partition region
[ https://issues.apache.org/jira/browse/GEODE-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428442#comment-17428442 ] ASF GitHub Bot commented on GEODE-9591: --- pdxcodemonkey commented on pull request #866: URL: https://github.com/apache/geode-native/pull/866#issuecomment-942397899 @jvarenina Just want to mention here, in case it's important going forward: The test `Apache.Geode.Client.UnitTests.ThinClientFunctionExecutionTests.OnServerHAExecuteFunctionTest` has failed on the Server 2019, VS 2019 release build job in CI (https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop/jobs/build-windows-2019-vs-2019-release/builds/122). It has passed on other Windows jobs (https://concourse.apachegeode-ci.info/teams/main/pipelines/geode-native-develop/jobs/build-windows-2016-vs-2017-release/builds/120 , e.g.), but failed first and then passed on retry. This seems at least plausibly related to this PR, so it's worth keeping an eye on. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Native client re-execute function even Function.isHA() is set to false and > redundancy in not used on partition region > - > > Key: GEODE-9591 > URL: https://issues.apache.org/jira/browse/GEODE-9591 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Jakov Varenina >Assignee: Jakov Varenina >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > This behavior of native client should be aligned with java client. Java > client in this case doesn't re-execute the function, but it trows the > exception that received > from the server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9732) CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException: CLUSTERDOWN The cluster is down
[
https://issues.apache.org/jira/browse/GEODE-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-9732.
Resolution: Duplicate
> CI Failure: ExpireNativeRedisAcceptanceTest fails with JedisClusterException:
> CLUSTERDOWN The cluster is down
> -
>
> Key: GEODE-9732
> URL: https://issues.apache.org/jira/browse/GEODE-9732
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> Looks like every test in the class fails when whatever caused this happens.
> {noformat}
> ExpireNativeRedisAcceptanceTest >
> usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at redis.clients.jedis.Connection.getIntegerReply(Connection.java:294)
> at redis.clients.jedis.Jedis.hset(Jedis.java:831)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:652)
> at redis.clients.jedis.JedisCluster$38.execute(JedisCluster.java:649)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.hset(JedisCluster.java:654)
> at
> org.apache.geode.redis.internal.executor.key.AbstractExpireIntegrationTest.usingHSETCommandToAlterAFieldValue_should_NOT_ClearExpirationTimeOnKey(AbstractExpireIntegrationTest.java:268)
> 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.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:121)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.util.stream.AbstractPipeline
[jira] [Commented] (GEODE-9175) Clean up the terminal output and log progress for benchmarks
[ https://issues.apache.org/jira/browse/GEODE-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428480#comment-17428480 ] ASF GitHub Bot commented on GEODE-9175: --- upthewaterspout opened a new pull request #157: URL: https://github.com/apache/geode-benchmarks/pull/157 Changing a bunch of debug output to info level to reduce the amount of noise the benchmark framework is printing out. This is not the full scope of GEODE-9195, which also is asking to print out progress as the test runs. Splitting this work out from #147. I still need to investigate the failure I saw with that PR and show that the progress logging has no measurable performance impact. But removing these extra log messages should get in as well. I left in the logProgress method that allows the benchmark tasks to log output to the gradle console if they want to, but we are not currently logging anything until I clean up #147. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Clean up the terminal output and log progress for benchmarks > > > Key: GEODE-9175 > URL: https://issues.apache.org/jira/browse/GEODE-9175 > Project: Geode > Issue Type: Improvement > Components: benchmarks >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > When developing a new benchmark with geode-benchmarks or testing out code > changes interactively, it would be nice to for the geode-benchmarks to log > the current throughput and latency numbers as the test is running, similar to > the way YCSB does. > This lets someone writing a new benchmark quickly eyeball if the performance > has changed, or if their warm up time is too short or too long because the > throughput fluctuates. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9676) Limit Radish RESP bulk input sizes for unauthenticated connections
[ https://issues.apache.org/jira/browse/GEODE-9676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9676: -- Labels: pull-request-available redis (was: redis) > Limit Radish RESP bulk input sizes for unauthenticated connections > -- > > Key: GEODE-9676 > URL: https://issues.apache.org/jira/browse/GEODE-9676 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > > Redis recently implemented a response to a CVE which allows for > unauthenticated users to craft RESP requests which consume a lot of memory. > Our implementation suffers from the same problem. > For example, a command input starting with `*` would result in the > JVM trying to allocate an array of size `MAX_INT`. > We need to be able to provide the same safeguards as Redis does. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou resolved GEODE-9677.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428498#comment-17428498
]
ASF subversion and git services commented on GEODE-9677:
Commit 00f92b660b6eff5cbd1dc349e0b795955bde728f in geode's branch
refs/heads/develop from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=00f92b6 ]
GEODE-9677: After provider sends ImageReply, requester could finish e… (#6992)
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9699) ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
[
https://issues.apache.org/jira/browse/GEODE-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-9699:
--
Assignee: Donal Evans
> ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
>
>
> Key: GEODE-9699
> URL: https://issues.apache.org/jira/browse/GEODE-9699
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Eric Zoerner
>Assignee: Donal Evans
>Priority: Major
> Labels: release-blocker
>
> The following redis TCL test fails when running against Geode for Redis:
> {code}
> # Geode fails with: Expected '1' to be equal to '0'
> test "ZUNIONSTORE against non-existing key doesn't set destination -
> $encoding" {
> r del "{slot}zseta"
> assert_equal 0 [r zunionstore "{slot}dst_key" 1 "{slot}zseta"]
> assert_equal 0 [r exists "{slot}dst_key"]
> }
> {code}
> Enable this test as part of this fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9715:
-
Component/s: tests
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9718: - Component/s: regions > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > > Mail discussion: [Region is not created on one of the > servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428506#comment-17428506
]
Alexander Murmann commented on GEODE-9715:
--
[~demery] shouldn't the AvailablePortHelper solve exactly this?
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428511#comment-17428511
]
Dale Emery commented on GEODE-9715:
---
{{AvailablePortHelper}} can't solve this. The problem is that the membership
port range (which was used in this test) overlaps with the ephemeral port range
on Linux, Windows, and macOS. By the time {{AvailablePortHelper}} tells you
that a port in that range is available, some other process may have already
bound to it.
This problem also exists in {{AvailablePort}} (which is part of the product).
But because this is an internal component, and nothing in the product currently
uses it to check availability of membership ports, I don't think this is a
release blocker.
I didn't realize this ticket existed, so I created another one:
https://issues.apache.org/jira/browse/GEODE-9725
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9699) ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
[
https://issues.apache.org/jira/browse/GEODE-9699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9699:
--
Labels: pull-request-available release-blocker (was: release-blocker)
> ZUNIONSTORE returns 1 instead of 0 when running against non-existing key
>
>
> Key: GEODE-9699
> URL: https://issues.apache.org/jira/browse/GEODE-9699
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Eric Zoerner
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available, release-blocker
>
> The following redis TCL test fails when running against Geode for Redis:
> {code}
> # Geode fails with: Expected '1' to be equal to '0'
> test "ZUNIONSTORE against non-existing key doesn't set destination -
> $encoding" {
> r del "{slot}zseta"
> assert_equal 0 [r zunionstore "{slot}dst_key" 1 "{slot}zseta"]
> assert_equal 0 [r exists "{slot}dst_key"]
> }
> {code}
> Enable this test as part of this fix.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9715:
-
Labels: (was: needsTriage)
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Xiaojian Zhou
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9715:
-
Affects Version/s: 1.15.0
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9733) Convert geode-unsafe to use junit5 test runner
Robert Houghton created GEODE-9733: -- Summary: Convert geode-unsafe to use junit5 test runner Key: GEODE-9733 URL: https://issues.apache.org/jira/browse/GEODE-9733 Project: Geode Issue Type: Improvement Components: tests Affects Versions: 1.15.0 Reporter: Robert Houghton As an isolated testable project, convert `geode-unsafe` to use the new JUnit5 test runner and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9733) Convert geode-unsafe to use junit5 test runner
[ https://issues.apache.org/jira/browse/GEODE-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Houghton reassigned GEODE-9733: -- Assignee: Robert Houghton > Convert geode-unsafe to use junit5 test runner > -- > > Key: GEODE-9733 > URL: https://issues.apache.org/jira/browse/GEODE-9733 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > > As an isolated testable project, convert `geode-unsafe` to use the new JUnit5 > test runner and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9733) Convert geode-unsafe to use junit5 test runner
[ https://issues.apache.org/jira/browse/GEODE-9733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9733: -- Labels: pull-request-available (was: ) > Convert geode-unsafe to use junit5 test runner > -- > > Key: GEODE-9733 > URL: https://issues.apache.org/jira/browse/GEODE-9733 > Project: Geode > Issue Type: Improvement > Components: tests >Affects Versions: 1.15.0 >Reporter: Robert Houghton >Priority: Major > Labels: pull-request-available > > As an isolated testable project, convert `geode-unsafe` to use the new JUnit5 > test runner and APIs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9731) Fix flaky PubSubIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-9731. --- Fix Version/s: 1.15.0 Resolution: Fixed > Fix flaky PubSubIntegrationTest > --- > > Key: GEODE-9731 > URL: https://issues.apache.org/jira/browse/GEODE-9731 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9731) Fix flaky PubSubIntegrationTest
[ https://issues.apache.org/jira/browse/GEODE-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428525#comment-17428525 ] ASF subversion and git services commented on GEODE-9731: Commit 449742840a227fb16eec20ae4fcb4315bbe347b4 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4497428 ] GEODE-9731: Fix flaky PubSubIntegrationTest (#6991) - Fix intermittent fail in testPatternAndRegularSubscribe > Fix flaky PubSubIntegrationTest > --- > > Key: GEODE-9731 > URL: https://issues.apache.org/jira/browse/GEODE-9731 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9627.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
> This work is related to GEODE-9618
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9627) Add service loader interface to register DataSerializableFixedIDs
[
https://issues.apache.org/jira/browse/GEODE-9627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428526#comment-17428526
]
ASF subversion and git services commented on GEODE-9627:
Commit 567460f627ba637d1b2783396de5b6374502473b in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=567460f ]
GEODE-9627: Add service provider interface to register DataSerializableFixedIDs
(#6891)
- This introduces a new SPI for registering DataSerializableFixedIDs.
Any new module should use this mechanism which allows for fixed Ids to
be registered when the JVM first starts up. Fixed Ids cannot be
unregistered and attempting to re-register a fixed Id will result in
an exception on startup.
- In order to implement this SPI one needs to provide a service loader
file -
resources/META-INF/services/org.apache.geode.internal.serialization.DataSerializableFixedIdRegistrant.
This file should contain the fully qualified name of a class which
implements DataSerializableFixedIdRegistrant. Examples can be seen in
the WAN, Lucene and Redis modules.
> Add service loader interface to register DataSerializableFixedIDs
> -
>
> Key: GEODE-9627
> URL: https://issues.apache.org/jira/browse/GEODE-9627
> Project: Geode
> Issue Type: Improvement
> Components: core, lucene, redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> External modules that require registering DataSerializableFixedIDs typically
> do so as part of their service loading initialization step. However, it seems
> that under some circumstances it may be necessary to have the DSFIDs be
> available even before the service is loaded as peers may be sending DSFID
> values even as a member is just starting up. Thus the DSFID should be made
> available even before a member is available to receive peer messages.
> This change introduces a service loader interface, {{DSFIDLoader}} which is
> called as part of the static initialization block in
> {{InternalDataSerializer}}. This will ensure that all reguired DSFIDs are
> available almost as soon as the JVM starts.
> This work is related to GEODE-9618
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9618) CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
[
https://issues.apache.org/jira/browse/GEODE-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe reassigned GEODE-9618:
-
Assignee: Jens Deppe
> CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
> ---
>
> Key: GEODE-9618
> URL: https://issues.apache.org/jira/browse/GEODE-9618
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest >
> testConcurrentHdel_whenServerCrashesAndRestarts FAILED
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:78)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.testConcurrentHdel_whenServerCrashesAndRestarts(HdelDUnitTest.java:137)
> Caused by:
> java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:74)
> ... 1 more
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The server
> had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:72)
> at
> io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy50.hdel(Unknown Source)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$null$2(HdelDUnitTest.java:130)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.retryableCommand(HdelDUnitTest.java:146)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$testConcurrentHdel_whenServerCrashesAndRestarts$3(HdelDUnitTest.java:130)
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The
> server had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:110)
> at
> io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120)
> at
> io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.cluster.ClusterCommand.complete(ClusterCommand.java:65)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:746)
> at
> io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:681)
> at
> io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:598)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
>
[jira] [Resolved] (GEODE-9618) CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
[
https://issues.apache.org/jira/browse/GEODE-9618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9618.
---
Fix Version/s: 1.15.0
Resolution: Fixed
Fixed by GEODE-9627
> CI Failure: HdelDUnitTest fails with RedisCommandExecutionException ERR
> ---
>
> Key: GEODE-9618
> URL: https://issues.apache.org/jira/browse/GEODE-9618
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Kirk Lund
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest >
> testConcurrentHdel_whenServerCrashesAndRestarts FAILED
> java.lang.RuntimeException: java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:78)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.testConcurrentHdel_whenServerCrashesAndRestarts(HdelDUnitTest.java:137)
> Caused by:
> java.util.concurrent.ExecutionException:
> io.lettuce.core.RedisCommandExecutionException: ERR The server had an
> internal error please try again
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at
> org.apache.geode.redis.ConcurrentLoopingThreads.await(ConcurrentLoopingThreads.java:74)
> ... 1 more
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The server
> had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:72)
> at
> io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy50.hdel(Unknown Source)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$null$2(HdelDUnitTest.java:130)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.retryableCommand(HdelDUnitTest.java:146)
> at
> org.apache.geode.redis.internal.executor.hash.HdelDUnitTest.lambda$testConcurrentHdel_whenServerCrashesAndRestarts$3(HdelDUnitTest.java:130)
> Caused by:
> io.lettuce.core.RedisCommandExecutionException: ERR The
> server had an internal error please try again
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:137)
> at
> io.lettuce.core.internal.ExceptionFactory.createExecutionException(ExceptionFactory.java:110)
> at
> io.lettuce.core.protocol.AsyncCommand.completeResult(AsyncCommand.java:120)
> at
> io.lettuce.core.protocol.AsyncCommand.complete(AsyncCommand.java:111)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.cluster.ClusterCommand.complete(ClusterCommand.java:65)
> at
> io.lettuce.core.protocol.CommandWrapper.complete(CommandWrapper.java:63)
> at
> io.lettuce.core.protocol.CommandHandler.complete(CommandHandler.java:746)
> at
> io.lettuce.core.protocol.CommandHandler.decode(CommandHandler.java:681)
> at
> io.lettuce.core.protocol.CommandHandler.channelRead(CommandHandler.java:598)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at
> io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at
> io.netty.channel.DefaultCha
[jira] [Updated] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
[ https://issues.apache.org/jira/browse/GEODE-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9729: - Affects Version/s: 1.15.0 > CI Failure: > PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED > - > > Key: GEODE-9729 > URL: https://issues.apache.org/jira/browse/GEODE-9729 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.cache.client.AllConnectionsInUseException > at > org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) > at > org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) > at > org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) > at > org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) > at java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9727) Redis Command COMMAND Should Throw Error With Invalid Arguments
[ https://issues.apache.org/jira/browse/GEODE-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9727: - Affects Version/s: 1.15.0 > Redis Command COMMAND Should Throw Error With Invalid Arguments > --- > > Key: GEODE-9727 > URL: https://issues.apache.org/jira/browse/GEODE-9727 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Priority: Major > > The Redis command COMMAND should throw an error when provided with an illegal > argument. > Native Redis behaves as follows: > COMMAND foo > (error) ERR Unknown subcommand or wrong number of arguments for 'foo'. Try > COMMAND HELP. > Our existing COMMANDimplementation does not provide an error messages for the > extra argument and just executes the COMMAND normally as if no additional > arguments were provided. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9724) CI Failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9724: - Affects Version/s: 1.14.1 > CI Failure: > RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable[from_v1.4.0] > FAILED > --- > > Key: GEODE-9724 > URL: https://issues.apache.org/jira/browse/GEODE-9724 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.1 >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest$1.run > in VM 2 running on Host 05a785bb07ad with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.rollLocatorToCurrent(RollingUpgradeDUnitTest.java:370) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeDUnitTest.doTestRollAll(RollingUpgradeDUnitTest.java:206) > at > org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnReplicatedRegion_dataserializable.testRollServersOnReplicatedRegion_dataserializable(RollingUpgradeRollServersOnReplicatedRegion_dataserializable.java:24) > 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.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(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.runners.ParentRunner.run(ParentRunner.java:413) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > 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 > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMe
[jira] [Updated] (GEODE-9697) CI Failure: ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest > dataReaderCanStillOnlyReadAfterFailover[clientVersion=1.7.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9697:
-
Affects Version/s: 1.15.0
> CI Failure: ClientDataAuthorizationUsingLegacySecurityWithFailoverDUnitTest >
> dataReaderCanStillOnlyReadAfterFailover[clientVersion=1.7.0] FAILED
> -
>
> Key: GEODE-9697
> URL: https://issues.apache.org/jira/browse/GEODE-9697
> Project: Geode
> Issue Type: Bug
> Components: membership, security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> Link:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
>
> Stacktrace:
> {noformat}
> [fatal 2021/10/07 01:17:43.168 UTC receiver,heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8-4> tid=1454]
> 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:1807)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveMemberMessage(GMSJoinLeave.java:725)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1367)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1303)
> 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:160)
> at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701)
> 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.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128
[jira] [Updated] (GEODE-9689) MultiUserAPIDUnitTest "Failed to find the authenticated user"
[
https://issues.apache.org/jira/browse/GEODE-9689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9689:
-
Affects Version/s: 1.15.0
> MultiUserAPIDUnitTest "Failed to find the authenticated user"
> -
>
> Key: GEODE-9689
> URL: https://issues.apache.org/jira/browse/GEODE-9689
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> In a PR [precheckin run for an unrelated
> change|https://concourse.apachegeode-ci.info/builds/86024#L60fbd583:610],
> {{MultiUserAPIDUnitTest}} failed with this exception:
> {noformat}
> MultiUserAPIDUnitTest > jsonFormatterOnTheClientWithSingleUser FAILED
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-3da43d93-7b04-56a2-b164-c14df052c421(402921:loner):57640:8f03df57:
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:559)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:623)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:500)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:119)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3048)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3163)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5612)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5590)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:157)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5048)
> at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1646)
> at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1633)
> at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:445)
> at
> org.apache.geode.security.MultiUserAPIDUnitTest.jsonFormatterOnTheClientWithSingleUser(MultiUserAPIDUnitTest.java:219)
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException: Failed to
> find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:124)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:259)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:254)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put70.cmdExecute(Put70.java:243)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:184)
> 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:1051)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1314)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> 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.lang.Thread.run(Thread.java:829)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9696) CI Failure: ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9696:
-
Affects Version/s: 1.15.0
> CI Failure: ClientAuthenticationDUnitTest >
> testCredentialsForNotifications[1.8.0] FAILED
> -
>
> Key: GEODE-9696
> URL: https://issues.apache.org/jira/browse/GEODE-9696
> Project: Geode
> Issue Type: Bug
> Components: membership, security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> Link:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk11/builds/247]
> Stacktrace:
> {noformat}
> ClientAuthenticationDUnitTest > testCredentialsForNotifications[1.8.0] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.ClientAuthenticationTestCase$$Lambda$474/0x000100416040.call
> in VM 1 running on Host
> heavy-lifter-f0dce14c-1683-56fa-bb43-d93a0d2513d8.c.apachegeode-ci.internal
> with 4 VMs at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) at
> org.apache.geode.test.dunit.VM.invoke(VM.java:473) at
> org.apache.geode.security.ClientAuthenticationTestCase.doTestCredentialsForNotifications(ClientAuthenticationTestCase.java:646)
> at
> org.apache.geode.security.ClientAuthenticationDUnitTest.testCredentialsForNotifications(ClientAuthenticationDUnitTest.java:100)
> Caused by: java.lang.AssertionError: Got unexpected
> exception when starting peer at
> org.apache.geode.test.dunit.Assert.fail(Assert.java:66) at
> org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:221)
> at
> org.apache.geode.security.SecurityTestUtils.createCacheServer(SecurityTestUtils.java:186)
> at
> org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:73)
> at
> org.apache.geode.security.ClientAuthenticationTestUtils.createCacheServer(ClientAuthenticationTestUtils.java:49)
> at
> org.apache.geode.security.ClientAuthenticationTestCase.lambda$doTestCredentialsForNotifications$41bb60fa$1(ClientAuthenticationTestCase.java:647)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> jdk.internal.reflect.GeneratedMethodAccessor232.invoke(Unknown Source)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> at sun.rmi.transport.Transport$1.run(Transport.java:200) at
> sun.rmi.transport.Transport$1.run(Transport.java:197) at
> java.security.AccessController.doPrivileged(Native Method) at
> sun.rmi.transport.Transport.serviceCall(Transport.java:196) at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:829) Caused by:
> org.apache.geode.GemFireConfigException: Problem configuring
> membership services at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(Clust
[jira] [Updated] (GEODE-9661) CI failure: SetRangeNativeRedisAcceptanceTest because native redis server went down
[ https://issues.apache.org/jira/browse/GEODE-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9661: - Affects Version/s: 1.15.0 > CI failure: SetRangeNativeRedisAcceptanceTest because native redis server > went down > --- > > Key: GEODE-9661 > URL: https://issues.apache.org/jira/browse/GEODE-9661 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > Labels: ci-failure, flaky > > Given that this is caused by a crash of the native redis server, this ticket > should not hold up a geode release. > SetRangeNativeRedisAcceptanceTest > setRange_replacesMiddle FAILED > redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The > cluster is down -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9653) ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest > serverVersioningTest[version=1.9.1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9653:
-
Affects Version/s: 1.15.0
> ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest >
> serverVersioningTest[version=1.9.1] FAILED
> ---
>
> Key: GEODE-9653
> URL: https://issues.apache.org/jira/browse/GEODE-9653
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.apache.geode.test.dunit.rules.tests.ClusterStartupRuleCanSpecifyOlderVersionsDUnitTest
> > serverVersioningTest[version=1.9.1] 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 350[fatal
> 2021/09/28 00:08:38.644 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 357[fatal
> 2021/09/28 00:08:38.657 UTC tid=47] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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)
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 364[fatal
> 2021/09/28 00:08:38.657 UTC tid=48] Exception in
> processing request from 10.0.0.30
> java.lang.Exception: Improperly configured client detected - use
> addPoolLocator to configure its locators instead of addPoolServer.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:374)
> 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.rules.ClusterStartupRule.after(ClusterStartupRule.java:186)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> a
[jira] [Updated] (GEODE-9651) LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing failed with AuthenticationRequiredException
[
https://issues.apache.org/jira/browse/GEODE-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9651:
-
Affects Version/s: 1.15.0
> LuceneClientSecurityPostProcessingDUnitTest > verifyPdxPostProcessing failed
> with AuthenticationRequiredException
> -
>
> Key: GEODE-9651
> URL: https://issues.apache.org/jira/browse/GEODE-9651
> Project: Geode
> Issue Type: Bug
> Components: lucene, security
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Priority: Major
> Labels: needsTriage
>
> This failure may be related to GEODE-9643.
> {noformat}
> org.apache.geode.cache.lucene.LuceneClientSecurityPostProcessingDUnitTest >
> verifyPdxPostProcessing 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 455[fatal
> 2021/09/28 00:23:59.861 UTC
> tid=125] Uncaught exception in thread Thread[ServerConnection on port 44721
> Thread 3,5,RMI Runtime]
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.bindSubject(ServerConnection.java:908)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:863)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1050)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1316)
> 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)
> 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.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> 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)
>
[jira] [Updated] (GEODE-9644) ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects FAILED
[
https://issues.apache.org/jira/browse/GEODE-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9644:
-
Affects Version/s: 1.15.0
> ClusterConfigLocatorRestartDUnitTest > serverRestartsAfterLocatorReconnects
> FAILED
> --
>
> Key: GEODE-9644
> URL: https://issues.apache.org/jira/browse/GEODE-9644
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> There is sequence of cascading exceptions that occur in the VMs and we need a
> more detailed investigation: Possible culprit may be the bind address in use
> exeception:
> [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0513/test-results/distributedTest/1632566050/*]
>
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest$$Lambda$163/1450009752.run
> in VM 0 running on Host
> heavy-lifter-2c03c48d-8a0c-58ae-bad6-31f64bb5400a.c.apachegeode-ci.internal
> with 5 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.waitForLocatorToReconnect(ClusterConfigLocatorRestartDUnitTest.java:225)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.serverRestartsAfterLocatorReconnects(ClusterConfigLocatorRestartDUnitTest.java:90)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> was not fulfilled within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:908)
> at
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest.lambda$waitForLocatorToReconnect$f182e747$2(ClusterConfigLocatorRestartDUnitTest.java:226)
> 8300 tests completed, 1 failed, 413 skipped{noformat}
> VM2 mentions that cluster membership has failed.
> {noformat}
> [vm2] [info 2021/09/25 09:36:44.487 UTC server-2
> tid=0x153] cluster membership failed due to
> [vm2]
> org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException:
> for testing
> [vm2] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1787)
> [vm2] at
> org.apache.geode.distributed.internal.membership.api.MembershipManagerHelper.crashDistributedSystem(MembershipManagerHelper.java:139)
> [vm2] at
> org.apache.geode.test.junit.rules.MemberStarterRule.forceDisconnectMember(MemberStarterRule.java:568)
> [vm2] at
> org.apache.geode.test.dunit.rules.MemberVM.lambda$forceDisconnect$bb17a952$1(MemberVM.java:90)
> [vm2] at
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
> [vm2] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm2] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm2] at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> [vm2] at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
> [vm2] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm2] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm2] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> [vm2] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm2] at sun.rmi.tran
[jira] [Updated] (GEODE-9643) LuceneClientSecurityDUnitTest > verifySearchIndexPermissions(UserNameAndExpectedResponse) [1] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9643:
-
Affects Version/s: 1.15.0
> LuceneClientSecurityDUnitTest >
> verifySearchIndexPermissions(UserNameAndExpectedResponse) [1] FAILED
>
>
> Key: GEODE-9643
> URL: https://issues.apache.org/jira/browse/GEODE-9643
> Project: Geode
> Issue Type: Bug
> Components: lucene, security
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: needsTriage
>
> Lucene Dunit tests during execution fails with
> AuthenticationRequiredException as it was unable to find an authenticated user
> [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0513/test-results/distributedTest/1632541236/*]
> {noformat}
> org.apache.geode.cache.lucene.LuceneClientSecurityDUnitTest >
> verifySearchIndexPermissions(UserNameAndExpectedResponse) [1] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.LuceneClientSecurityDUnitTest$$Lambda$64/245947456.run
> in VM 3 running on Host
> heavy-lifter-4213e41d-1d6e-5688-bf19-db9dcbeeb795.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.cache.lucene.LuceneClientSecurityDUnitTest.verifySearchIndexPermissions(LuceneClientSecurityDUnitTest.java:67)
> Caused by:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerOperationException: remote server on
> heavy-lifter-4213e41d-1d6e-5688-bf19-db9dcbeeb795(13832:loner):44794:2740b11a:
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:215)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:156)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:390)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at
> org.apache.geode.cache.lucene.internal.LuceneServiceImpl.waitUntilFlushed(LuceneServiceImpl.java:679)
> at
> org.apache.geode.cache.lucene.LuceneClientSecurityDUnitTest.executeTextSearch(LuceneClientSecurityDUnitTest.java:108)
> at
> org.apache.geode.cache.lucene.LuceneClientSecurityDUnitTest.lambda$verifySearchIndexPermissions$ca7f4b9f$1(LuceneClientSecurityDUnitTest.java:68)
> Caused by:
> org.apache.geode.cache.client.ServerOperationException: remote
> server on
> heavy-lifter-4213e41d-1d6e-5688-bf19-db9dcbeeb795(13832:loner):44794:2740b11a:
> org.apache.geode.security.AuthenticationRequiredException: Failed to find
> the authenticated user.
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:559)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:623)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:500)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:816)
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionOp.execute(ExecuteRegionFunctionOp.java:90)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.executeFunction(ServerRegionProxy.java:685)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:206)
> ... 6 more
> Caused by:
> org.apache.geode.security.AuthenticationRequiredException:
> Failed to find the authenticated user.
> at
> org.apache.geode.internal.security.IntegratedSecurityService.getSubject(IntegratedSecurityService.java:123)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.authorize(IntegratedSecurityService.java:249)
> at
> java.util.Collections$SingletonList.forEach(Collections.java:4824)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.c
[jira] [Updated] (GEODE-9638) CI failure: DeployedJarTest getDeployedFileName failed on Windows intermittently
[ https://issues.apache.org/jira/browse/GEODE-9638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9638: - Affects Version/s: 1.15.0 > CI failure: DeployedJarTest getDeployedFileName failed on Windows > intermittently > - > > Key: GEODE-9638 > URL: https://issues.apache.org/jira/browse/GEODE-9638 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > Labels: flaky, needsTriage > > org.apache.geode.deployment.internal.DeployedJarTest > getDeployedFileName > FAILED > java.nio.file.DirectoryNotEmptyException: > C:\Users\geode\AppData\Local\Temp\javaCompiler2976436474406314797\classes > at > sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:266) > at > sun.nio.fs.AbstractFileSystemProvider.delete(AbstractFileSystemProvider.java:103) > at java.nio.file.Files.delete(Files.java:1126) > at org.apache.commons.io.FileUtils.delete(FileUtils.java:1175) > at > org.apache.commons.io.FileUtils.deleteDirectory(FileUtils.java:1194) > at > org.apache.geode.test.compiler.JavaCompiler.compile(JavaCompiler.java:91) > at > org.apache.geode.test.compiler.JarBuilder.buildJarFromClassNames(JarBuilder.java:83) > at > org.apache.geode.deployment.internal.DeployedJarTest.createJarFile(DeployedJarTest.java:82) > at > org.apache.geode.deployment.internal.DeployedJarTest.getDeployedFileName(DeployedJarTest.java:65) > see: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk8/builds/206 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9721) the constant names for redis gemfire properties should contain GEODE_FOR_REDIS
[ https://issues.apache.org/jira/browse/GEODE-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9721: - Affects Version/s: 1.15.0 > the constant names for redis gemfire properties should contain GEODE_FOR_REDIS > -- > > Key: GEODE-9721 > URL: https://issues.apache.org/jira/browse/GEODE-9721 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The following constant names in ConfigurationProperties should all be > renamed: REDIS_PORT, REDIS_USERNAME, REDIS_ENABLED, REDIS_BIND_ADDRESS > to: GEODE_FOR_REDIS_PORT, GEODE_FOR_REDIS_USERNAME, GEODE_FOR_REDIS_ENABLED, > GEODE_FOR_REDIS_BIND_ADDRESS. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
Darrel Schneider created GEODE-9734: --- Summary: ClientPublisher has race causing it to never publish a single message Key: GEODE-9734 URL: https://issues.apache.org/jira/browse/GEODE-9734 Project: Geode Issue Type: Bug Components: redis Reporter: Darrel Schneider The ClientPublisher has a race condition that can cause it to add a message to the queue but not drain it right away. The msg will never be published unless that client publishes a second message. The order of events that cause the race is: 1. drainerThread: set active and publishes current batch 2. drainerThread: calls batch.fill and gets nothing 3. publishThread: adds msg to queue 4. publishThread: tests "active" see it is true so it does not call fillBatchIfNeeded 5. drainerThread: sets "active" to false We now have one msg in the queue that will not be published until we add another msg to the queue. This should be easy to fix. All we need to do in the drainerThread is one more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-9734: --- Assignee: Darrel Schneider > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9734: - Labels: needsTriage (was: ) > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9734: Affects Version/s: 1.15.0 > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage, pull-request-available > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9734: -- Labels: needsTriage pull-request-available (was: needsTriage) > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage, pull-request-available > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9734) ClientPublisher has race causing it to never publish a single message
[ https://issues.apache.org/jira/browse/GEODE-9734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9734: Labels: pull-request-available (was: needsTriage pull-request-available) > ClientPublisher has race causing it to never publish a single message > - > > Key: GEODE-9734 > URL: https://issues.apache.org/jira/browse/GEODE-9734 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > The ClientPublisher has a race condition that can cause it to add a message > to the queue but not drain it right away. The msg will never be published > unless that client publishes a second message. > The order of events that cause the race is: > 1. drainerThread: set active and publishes current batch > 2. drainerThread: calls batch.fill and gets nothing > 3. publishThread: adds msg to queue > 4. publishThread: tests "active" see it is true so it does not call > fillBatchIfNeeded > 5. drainerThread: sets "active" to false > We now have one msg in the queue that will not be published until we add > another msg to the queue. > This should be easy to fix. All we need to do in the drainerThread is one > more check of the queue after setting active to false -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9369) Command to copy region entries from a WAN site to another.
[ https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428612#comment-17428612 ] ASF subversion and git services commented on GEODE-9369: Commit c106e017b2e2ddc07a299bc3d47f6a4baae1451a in geode's branch refs/heads/develop from Alberto Gomez [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c106e01 ] GEODE-9369: Command to copy region entries from a WAN site to another (#6833) * GEODE-9369: Command to copy region entries from a WAN site to another (#6601) * GEODE-9369: Command to copy region entries from a WAN site to another The command has been implemented as proposed in https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN with some modifications with respect to the initial proposal. The command will get the entries of a region in a WAN site and will put them in batches that will be sent by a gateway sender to a remote WAN site. * GEODE-9369: Remove comments added to geode-gfsh/src/test/resources/expected-pom.xml * GEODE-9369: Changes after review * GEODE-9369: Update with Kirk's review comments * GEODE-9369: Update with boglesby's review comments * GEODE-9369: Changes after boglesby's review * GEODE-9369: Updated with davebarnes97's review comments. * GEODE-9369: More changes after davebarnes97's review * GEODE-9369: Updated with DonalEvan's comments * GEODE-9369: Small refactoring: Use CompletableFuture instead of Callable + FutureTask * GEODE-9369: Fix race condition added in previous commit * GEODE-9369: Small change of re-review from DonalEvans * GEODE-9369: Fix esporadic test failures due to error log. * GEODE-9369: Changes required after rebasing to develop * GEODE-9369: Add changes suggested by klund - Remove sleeps in unit tests that made some of them flaky, especially in windows - Remove use of DEEP_STUBS in mocks - Move new function to geode-wan - Handle the lifecycle of the executor used by the function in a new CacheService class in wan - Remove partial mocking in unit tests * GEODE-9369: Create a new CliFunction inside geode-core In order to be able to use CliFunction in WanCopyRegion without adding a dependency to geode-gfsh, I created a CliFunction class inside geode-core which is a copy of that same class in geode-gfsh. At first I thought about moving the class from geode-gfsh to geode-core which seemed more logical but I realized it would break the compatibility of a public API. * GEODE-9369: Changes after klund's review * GEODE-9369: More changes after Kirk Lund's review * GEODE-9369: Some more changes after Kirk's review * GEODE-9369: Changes required after rebasing * GEODE-9369: More changes after Kirk's review * GEODE-9369: Update test case that was changed wrongly in a previous refactor > Command to copy region entries from a WAN site to another. > -- > > Key: GEODE-9369 > URL: https://issues.apache.org/jira/browse/GEODE-9369 > Project: Geode > Issue Type: New Feature > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > As described in RFC: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN] > it is proposed to implement a command that copies the entries of a region in > a WAN site to the same region in another WAN site by using WAN replication. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428640#comment-17428640
]
ASF subversion and git services commented on GEODE-9581:
Commit 3f66f450e18f0b5af3f9dd7be68764d54c57f01c in geode's branch
refs/heads/develop from Alberto Gomez
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3f66f45 ]
GEODE-9581: Set a higher number of retries to get transction events in tests to
avoid flakyness in test case (#6990)
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> 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.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
