[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460459#comment-17460459
 ] 

ASF subversion and git services commented on GEODE-8644:


Commit fa82cd5ba4703b642cc9e692a3724dea78a6dd76 in geode's branch 
refs/heads/feature/GEODE-8644 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fa82cd5 ]

GEODE-8644: CME will send additional UPDATE_VERSION event via serial gateway 
sender

co-authored-by: mhansonp 


> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() 
> intermittently fails when queues drain too slowly
> ---
>
> Key: GEODE-8644
> URL: https://issues.apache.org/jira/browse/GEODE-8644
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Benjamin P Ross
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> Currently the test 
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() 
> relies on a 2 second delay to allow for queues to finish draining after 
> finishing the put operation. If queues take longer than 2 seconds to drain 
> the test will fail. We should change the test to wait for the queues to be 
> empty with a long timeout in case the queues never fully drain.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly

[Xiaojian Zhou (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Xiaojian Zhou reassigned GEODE-8644:


Assignee: Xiaojian Zhou  (was: Mark Hanson)

> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() 
> intermittently fails when queues drain too slowly
> ---
>
> Key: GEODE-8644
> URL: https://issues.apache.org/jira/browse/GEODE-8644
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Benjamin P Ross
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> Currently the test 
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() 
> relies on a 2 second delay to allow for queues to finish draining after 
> finishing the put operation. If queues take longer than 2 seconds to drain 
> the test will fail. We should change the test to wait for the queues to be 
> empty with a long timeout in case the queues never fully drain.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9788) Develop PubSub Benchmark Tests

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460453#comment-17460453
 ] 

ASF GitHub Bot commented on GEODE-9788:
---

ezoerner commented on pull request #161:
URL: https://github.com/apache/geode-benchmarks/pull/161#issuecomment-995512152


   I'm good with this being merged


-- 
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


> Develop PubSub Benchmark Tests
> --
>
> Key: GEODE-9788
> URL: https://issues.apache.org/jira/browse/GEODE-9788
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
>  Labels: pull-request-available
>
> Develop a suite of benchmarking tests for the pubsub API that benchmark the 
> comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of 
> the pubsub that allows us to monitor the performance over time and compared 
> to native Redis.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9788) Develop PubSub Benchmark Tests

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460410#comment-17460410
 ] 

ASF GitHub Bot commented on GEODE-9788:
---

ezoerner commented on pull request #161:
URL: https://github.com/apache/geode-benchmarks/pull/161#issuecomment-995430162


   My concern at this point is that even with no code changes the average 
latency is showing over a 5% difference in average latency between runs. This 
could cause the benchmark to fail in CI. This is based on only a couple runs, 
though. I will try to run it again to get more data.


-- 
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


> Develop PubSub Benchmark Tests
> --
>
> Key: GEODE-9788
> URL: https://issues.apache.org/jira/browse/GEODE-9788
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
>  Labels: pull-request-available
>
> Develop a suite of benchmarking tests for the pubsub API that benchmark the 
> comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of 
> the pubsub that allows us to monitor the performance over time and compared 
> to native Redis.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9788) Develop PubSub Benchmark Tests

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460409#comment-17460409
 ] 

ASF GitHub Bot commented on GEODE-9788:
---

ezoerner commented on pull request #161:
URL: https://github.com/apache/geode-benchmarks/pull/161#issuecomment-995429098


   Just by turning on `withVerification=true`, it slows down the subscribers in 
responding to the pubsub messages by causing them to log a message back to the 
benchmark controller. This increases the time it takes to process the message 
significantly, and for the benchmark metrics this is equivalent to geode taking 
longer to deliver the message to the subscriber. This is indeed reflected in 
large increase in the average latency reported by the benchmark.


-- 
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


> Develop PubSub Benchmark Tests
> --
>
> Key: GEODE-9788
> URL: https://issues.apache.org/jira/browse/GEODE-9788
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
>  Labels: pull-request-available
>
> Develop a suite of benchmarking tests for the pubsub API that benchmark the 
> comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of 
> the pubsub that allows us to monitor the performance over time and compared 
> to native Redis.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9819) Client socket leak in CacheClientNotifier.registerClientInternal when error conditions occur for the durable client

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9819:
--
Labels: GeodeOperationAPI blocks-1.15.0​ pull-request-available  (was: 
GeodeOperationAPI blocks-1.15.0​)

> Client socket leak in CacheClientNotifier.registerClientInternal when error 
> conditions occur for the durable client
> ---
>
> Key: GEODE-9819
> URL: https://issues.apache.org/jira/browse/GEODE-9819
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, core
>Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0
>Reporter: Leon Finker
>Assignee: Darrel Schneider
>Priority: Critical
>  Labels: GeodeOperationAPI, blocks-1.15.0​, pull-request-available
>
> In CacheClientNotifier.registerClientInternal client socket can be left half 
> open and not properly closed when error conditions occur. Such as the case of:
> {code:java}
> } else {
>   // The existing proxy is already running (which means that another
>   // client is already using this durable id.
>   unsuccessfulMsg =
>   String.format(
>   "The requested durable client has the same identifier ( %s ) as an 
> existing durable client ( %s ). Duplicate durable clients are not allowed.",
>   clientProxyMembershipID.getDurableId(), cacheClientProxy);
>   logger.warn(unsuccessfulMsg);
>   // Set the unsuccessful response byte.
>   responseByte = Handshake.REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT;
> } {code}
> It considers the current client connect attempt to have failed. It writes 
> this response back to client: REPLY_EXCEPTION_DUPLICATE_DURABLE_CLIENT. This 
> will cause the client to throw ServerRefusedConnectionException. What seems 
> wrong about this method is that even though it sets "unsuccessfulMsg" and 
> correctly sends back a handshake saying the client is rejected, it does not 
> throw an exception and it does not close "socket". I think right before it 
> calls performPostAuthorization it should do the followiing:
> {code:java}
> if (unsuccessfulMsg != null) {
>   try {
> socket.close();
>   } catch (IOException ignore) {
>   }
>  } else {
> performPostAuthorization(...)
> }{code}
> Full discussion details can be found at 
> https://markmail.org/thread/2gqmbq2m57pz7pxu



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9898) bump log4j to 2.16.0

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460327#comment-17460327
 ] 

ASF subversion and git services commented on GEODE-9898:


Commit 6fc4ee31a4b4848250a4c37750aa3fe51958a7e5 in geode's branch 
refs/heads/master from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fc4ee3 ]

GEODE-9898: Bump log4j from 2.15.0 to 2.16.0

(cherry-picked from commit 7bec7474c1fb6794daf199276d0eea8cb40a8206))


> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9877) GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460326#comment-17460326
 ] 

ASF subversion and git services commented on GEODE-9877:


Commit e3ab8cae9bbf4518416bef4ecba99792bfc25224 in geode's branch 
refs/heads/master from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=e3ab8ca ]

GEODE-9877: Use ServerSocket to create interfering port (#7182)

- This is a manual backport of 310c647da6 since there are a lot of
  conflicts when cherry picking and the fix is quite trivial.

> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse failed
> --
>
> Key: GEODE-9877
> URL: https://issues.apache.org/jira/browse/GEODE-9877
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.14.1, 1.15.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/43]
>  failed with 
> GeodeRedisServerStartupDUnitTest. startupFailsGivenPortAlreadyInUse
> {noformat}
> 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.Socket.bind(Socket.java:662)
>   at 
> org.apache.geode.redis.GeodeRedisServerStartupDUnitTest.startupFailsGivenPortAlreadyInUse(GeodeRedisServerStartupDUnitTest.java:115)
>   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.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:138)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>   at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
>   at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
>   at 
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
>   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 
> 

[jira] [Closed] (GEODE-9898) bump log4j to 2.16.0

[Owen Nichols (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Owen Nichols closed GEODE-9898.
---

> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator

[Udo Kohlmeyer (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Kohlmeyer updated GEODE-9857:
-
Labels: GeodeOperationAPI  (was: GeodeOperationAPI needsTriage)

> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
>     org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>  
>     Expecting value to be true but was false within 5 minutes.
>         at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
>         at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
>         at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
>         at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
>         Caused by:
>         org.opentest4j.AssertionFailedError: 
>         Expecting value to be true but was false
>             at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown 
> Source)
>             at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>             at 
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
>             at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator

[Udo Kohlmeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460283#comment-17460283
 ] 

Udo Kohlmeyer commented on GEODE-9857:
--

This test also has not failed since. Last available build is build 61 where 
this test has not failed since the failure in build 24.

> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
>     org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>  
>     Expecting value to be true but was false within 5 minutes.
>         at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
>         at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
>         at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
>         at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
>         Caused by:
>         org.opentest4j.AssertionFailedError: 
>         Expecting value to be true but was false
>             at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown 
> Source)
>             at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>             at 
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
>             at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator

[Udo Kohlmeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460282#comment-17460282
 ] 

Udo Kohlmeyer commented on GEODE-9857:
--

This seems to be a one time failure of this test. It seems the locator had not 
stopped before the restarting of the locator was attempted. In future this 
problem might be resolved by waiting for the locator to have stopped correctly 
before trying to restart it.

> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
>     org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>  
>     Expecting value to be true but was false within 5 minutes.
>         at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
>         at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
>         at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
>         at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
>         at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
>         Caused by:
>         org.opentest4j.AssertionFailedError: 
>         Expecting value to be true but was false
>             at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown 
> Source)
>             at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>             at 
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
>             at 
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
>  {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9428) CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error

[Jens Deppe (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe resolved GEODE-9428.
---
Fix Version/s: 1.15.0
   Resolution: Fixed

> CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error
> --
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Hale Bales
>Priority: Major
> Fix For: 1.15.0
>
>
> *This ticket tracks failures seen in NativeRedisAcceptanceTests due to 
> non-Geode code. It is closed because no work will be done in the Geode 
> project to fix this issue. If the issue becomes unbearable, a bug should be 
> opened with Redis: 
> [https://github.com/redis/redis/issues|https://github.com/redis/redis/issues*]*
> CI run is here: 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311]
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
>  > testPSetEX 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.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at 
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at 
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at 
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> 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.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:120)
> 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.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 
> 

[jira] [Assigned] (GEODE-9428) CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error

[Jens Deppe (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe reassigned GEODE-9428:
-

Assignee: Jens Deppe

> CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error
> --
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Hale Bales
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.15.0
>
>
> *This ticket tracks failures seen in NativeRedisAcceptanceTests due to 
> non-Geode code. It is closed because no work will be done in the Geode 
> project to fix this issue. If the issue becomes unbearable, a bug should be 
> opened with Redis: 
> [https://github.com/redis/redis/issues|https://github.com/redis/redis/issues*]*
> CI run is here: 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311]
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
>  > testPSetEX 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.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at 
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at 
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at 
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> 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.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:120)
> 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.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 
> 

[jira] [Commented] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed

[Jens Deppe (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460277#comment-17460277
 ] 

Jens Deppe commented on GEODE-9810:
---

This also addresses GEODE-9428

> CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
> --
>
> Key: GEODE-9810
> URL: https://issues.apache.org/jira/browse/GEODE-9810
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Xiaojian Zhou
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
>  
> {code:java}
> > Task :geode-for-redis:acceptanceTest
> NativeRedisClusterTest > testEachProxyReturnsExposedPorts FAILED
> java.lang.AssertionError: 
> Expecting actual:
>   [44073, 45679, 36065, 40077, 42137]
> to contain exactly in any order:
>   [40077, 45679, 33425, 36065, 42137, 44073]
> but could not find the following elements:
>   [33425]
> at 
> org.apache.geode.redis.NativeRedisClusterTest.testEachProxyReturnsExposedPorts(NativeRedisClusterTest.java:48)
> 1385 tests completed, 1 failed, 2 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-artifacts/1637046056/acceptancetestfiles-openjdk8-1.15.0-build.0662.tgz
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9428) CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460276#comment-17460276
 ] 

ASF subversion and git services commented on GEODE-9428:


Commit 0aced7f49a205eacb072f506ac23bcce09430131 in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0aced7f ]

GEODE-9810: More robust waiting for native Redis cluster to start (#7192)


- This fix also addresses GEODE-9428 where CLUSTERDOWN is occasionally
  reported.
- The NativeRedisClusterTestRule now checks each node to make sure they
  are all reporting the correct node count instead of just one. Nodes
  are not always all ready at once.
- When processing CLUSTER INFO sometimes a 'master' reports with no
  slots which indicates it is transitioning or will become a replica.
  Originally we would mark such a node as a replica even before it had
  fully transitioned. However, this would cause problems since it then
  resulted in a too early report that the cluster was ready.


> CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error
> --
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Hale Bales
>Priority: Major
>
> *This ticket tracks failures seen in NativeRedisAcceptanceTests due to 
> non-Geode code. It is closed because no work will be done in the Geode 
> project to fix this issue. If the issue becomes unbearable, a bug should be 
> opened with Redis: 
> [https://github.com/redis/redis/issues|https://github.com/redis/redis/issues*]*
> CI run is here: 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311]
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
>  > testPSetEX 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.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at 
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at 
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at 
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> 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.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 

[jira] [Commented] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460275#comment-17460275
 ] 

ASF subversion and git services commented on GEODE-9810:


Commit 0aced7f49a205eacb072f506ac23bcce09430131 in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0aced7f ]

GEODE-9810: More robust waiting for native Redis cluster to start (#7192)


- This fix also addresses GEODE-9428 where CLUSTERDOWN is occasionally
  reported.
- The NativeRedisClusterTestRule now checks each node to make sure they
  are all reporting the correct node count instead of just one. Nodes
  are not always all ready at once.
- When processing CLUSTER INFO sometimes a 'master' reports with no
  slots which indicates it is transitioning or will become a replica.
  Originally we would mark such a node as a replica even before it had
  fully transitioned. However, this would cause problems since it then
  resulted in a too early report that the cluster was ready.


> CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
> --
>
> Key: GEODE-9810
> URL: https://issues.apache.org/jira/browse/GEODE-9810
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Xiaojian Zhou
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
>  
> {code:java}
> > Task :geode-for-redis:acceptanceTest
> NativeRedisClusterTest > testEachProxyReturnsExposedPorts FAILED
> java.lang.AssertionError: 
> Expecting actual:
>   [44073, 45679, 36065, 40077, 42137]
> to contain exactly in any order:
>   [40077, 45679, 33425, 36065, 42137, 44073]
> but could not find the following elements:
>   [33425]
> at 
> org.apache.geode.redis.NativeRedisClusterTest.testEachProxyReturnsExposedPorts(NativeRedisClusterTest.java:48)
> 1385 tests completed, 1 failed, 2 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-artifacts/1637046056/acceptancetestfiles-openjdk8-1.15.0-build.0662.tgz
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed

[Jens Deppe (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe updated GEODE-9810:
--
Labels: pull-request-available  (was: needsTriage pull-request-available)

> CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
> --
>
> Key: GEODE-9810
> URL: https://issues.apache.org/jira/browse/GEODE-9810
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Xiaojian Zhou
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
>  
> {code:java}
> > Task :geode-for-redis:acceptanceTest
> NativeRedisClusterTest > testEachProxyReturnsExposedPorts FAILED
> java.lang.AssertionError: 
> Expecting actual:
>   [44073, 45679, 36065, 40077, 42137]
> to contain exactly in any order:
>   [40077, 45679, 33425, 36065, 42137, 44073]
> but could not find the following elements:
>   [33425]
> at 
> org.apache.geode.redis.NativeRedisClusterTest.testEachProxyReturnsExposedPorts(NativeRedisClusterTest.java:48)
> 1385 tests completed, 1 failed, 2 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-artifacts/1637046056/acceptancetestfiles-openjdk8-1.15.0-build.0662.tgz
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed

[Jens Deppe (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe resolved GEODE-9810.
---
Fix Version/s: 1.15.0
 Assignee: Jens Deppe
   Resolution: Fixed

> CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
> --
>
> Key: GEODE-9810
> URL: https://issues.apache.org/jira/browse/GEODE-9810
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Xiaojian Zhou
>Assignee: Jens Deppe
>Priority: Major
>  Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
>  
> {code:java}
> > Task :geode-for-redis:acceptanceTest
> NativeRedisClusterTest > testEachProxyReturnsExposedPorts FAILED
> java.lang.AssertionError: 
> Expecting actual:
>   [44073, 45679, 36065, 40077, 42137]
> to contain exactly in any order:
>   [40077, 45679, 33425, 36065, 42137, 44073]
> but could not find the following elements:
>   [33425]
> at 
> org.apache.geode.redis.NativeRedisClusterTest.testEachProxyReturnsExposedPorts(NativeRedisClusterTest.java:48)
> 1385 tests completed, 1 failed, 2 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-artifacts/1637046056/acceptancetestfiles-openjdk8-1.15.0-build.0662.tgz
> {code}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9902) Modify ZUnionStore and ZInterStore storing methods

[Darrel Schneider (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460265#comment-17460265
 ] 

Darrel Schneider commented on GEODE-9902:
-

For SortedSet you will want a DeltaInfo that is a variant of: 
AddByteArrayDoublePairs. Same data structures but Replace instead of Add

> Modify ZUnionStore and ZInterStore storing methods
> --
>
> Key: GEODE-9902
> URL: https://issues.apache.org/jira/browse/GEODE-9902
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
>  Labels: release-blocker
>
> Modify the way Redis SortedSets store the members for the ZUnionStore and 
> ZInterStore. It should follow what Redis Sets are doing for SUnionStore and 
> SInterStore.  This is specifically related to the use of DeltaInfos.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9902) Modify ZUnionStore and ZInterStore storing methods

[Wayne (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wayne updated GEODE-9902:
-
Description: Modify the way Redis SortedSets store the members for the 
ZUnionStore and ZInterStore. It should follow what Redis Sets are doing for 
SUnionStore and SInterStore.  This is specifically related to the use of 
DeltaInfos.  (was: Modify the way Redis SortedSets store the members for the 
ZUnionStore and ZInterStore. It should follow what Redis Sets are doing for 
SUnionStore and SInterStore.)

> Modify ZUnionStore and ZInterStore storing methods
> --
>
> Key: GEODE-9902
> URL: https://issues.apache.org/jira/browse/GEODE-9902
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
>
> Modify the way Redis SortedSets store the members for the ZUnionStore and 
> ZInterStore. It should follow what Redis Sets are doing for SUnionStore and 
> SInterStore.  This is specifically related to the use of DeltaInfos.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9902) Modify ZUnionStore and ZInterStore storing methods

[Wayne (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Wayne updated GEODE-9902:
-
Labels: release-blocker  (was: )

> Modify ZUnionStore and ZInterStore storing methods
> --
>
> Key: GEODE-9902
> URL: https://issues.apache.org/jira/browse/GEODE-9902
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Priority: Major
>  Labels: release-blocker
>
> Modify the way Redis SortedSets store the members for the ZUnionStore and 
> ZInterStore. It should follow what Redis Sets are doing for SUnionStore and 
> SInterStore.  This is specifically related to the use of DeltaInfos.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-9902) Modify ZUnionStore and ZInterStore storing methods

[Kristen (Jira)]

Kristen created GEODE-9902:
--

 Summary: Modify ZUnionStore and ZInterStore storing methods
 Key: GEODE-9902
 URL: https://issues.apache.org/jira/browse/GEODE-9902
 Project: Geode
  Issue Type: Improvement
  Components: redis
Affects Versions: 1.15.0
Reporter: Kristen


Modify the way Redis SortedSets store the members for the ZUnionStore and 
ZInterStore. It should follow what Redis Sets are doing for SUnionStore and 
SInterStore.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9823) List supported subcommands in CLIENT and CLUSTER error messages.

[Kristen (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kristen resolved GEODE-9823.

Resolution: Fixed

> List supported subcommands in CLIENT and CLUSTER error messages.
> 
>
> Key: GEODE-9823
> URL: https://issues.apache.org/jira/browse/GEODE-9823
> Project: Geode
>  Issue Type: Improvement
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Kristen
>Assignee: Kristen
>Priority: Major
>
> Change output of CLIENT and CLUSTER error messages to display/output 
> currently supported subcommands rather than "Try CLUSTER HELP" or "Try CLIENT 
> HELP".



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460258#comment-17460258
 ] 

ASF subversion and git services commented on GEODE-9850:


Commit 3b2595af2b610a5118a074df0f064672aa451c44 in geode's branch 
refs/heads/develop from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b2595a ]

GEODE-9850: resolve the flaky test in getting the oldest tombstone (#7198)



> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> First saw this failure in PR pipeline on support/1.13 here: 
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest > 
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
>  in VM 0 running on Host 9a305b2d7db7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError: 
> Expecting:
>  <-1637701703343L>
> to be greater than:
>  <0L> 
> at 
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
>  {code}
> I believe the fix is to wrap this assertion in an awaitility call.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-6751) CI failure: AcceptanceTestOpenJDK8 ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-6751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460246#comment-17460246
 ] 

Geode Integration commented on GEODE-6751:
--

Seen in [upgrade-test-openjdk8 
#60|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/60]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0743/test-results/upgradeTest/1639601519/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0743/test-artifacts/1639601519/upgradetestfiles-openjdk8-1.15.0-build.0743.tgz].

> CI failure: AcceptanceTestOpenJDK8 
> ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator failure
> -
>
> Key: GEODE-6751
> URL: https://issues.apache.org/jira/browse/GEODE-6751
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.15.0
>Reporter: Scott Jewell
>Priority: Major
>
> Assertion failure in 
> ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator
> Appears to be a new bug
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest
>  > useCurrentGfshToConnectToOlderLocator FAILED
> java.lang.AssertionError: 
> Expecting:
>  <"
> (1) Executing - connect
> Connecting to Locator at [host=localhost, port=10334] ..
> Exception caused JMX Manager startup to fail because: 'HTTP service 
> failed to start'
> ">
> to contain:
>  <"Cannot use a"> 
> at 
> org.apache.geode.management.internal.cli.commands.ConnectCommandAcceptanceTest.useCurrentGfshToConnectToOlderLocator(ConnectCommandAcceptanceTest.java:50)
> 60 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-results/acceptanceTest/1557290414/*]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0258/test-artifacts/1557290414/acceptancetestfiles-OpenJDK8-1.10.0-SNAPSHOT.0258.tgz*]
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460245#comment-17460245
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#21|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/21]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639565952/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639565952/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.6
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Comment Edited] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on cli

[Steve Sienkowski (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460242#comment-17460242
 ] 

Steve Sienkowski edited comment on GEODE-8616 at 12/15/21, 8:57 PM:


largeObjectGetWithReadTimeout failed on a linux run of 
[distributed-test-openjdk11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/11].
[https://hydradb.hdb.gemfire-ci.info/hdb/testresult/12689867]

 


was (Author: ssienkowski):
largeObjectGetWithReadTimeout failed on a linux run of 
[distributed-test-openjdk11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/11].

> ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException fails with 
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeOperationAPI, flaky-test
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz, 
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
>  in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool 
> unexpected socket timed out on client connection=Pooled Connection to 
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
> connect after 1 attempts
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at 
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at 
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at 
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at 
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with ServerConnectivityException : Pool unexpected socket timed out on client

[Steve Sienkowski (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460242#comment-17460242
 ] 

Steve Sienkowski commented on GEODE-8616:
-

largeObjectGetWithReadTimeout failed on a linux run of 
[distributed-test-openjdk11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/11].

> ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException fails with 
> ServerConnectivityException : Pool unexpected socket timed out on client
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeOperationAPI, flaky-test
> Attachments: hansonm-findfailures-11-10-2021-23-52-38-logs.tgz, 
> hansonm-findfailures-11-10-2021-23-52-45-logs.tgz
>
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
>  in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool 
> unexpected socket timed out on client connection=Pooled Connection to 
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
> connect after 1 attempts
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at 
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at 
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at 
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at 
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at 
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at 
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at 
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at 
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at 
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-7455) CI Failure: AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean Failed

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-7455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460239#comment-17460239
 ] 

Geode Integration commented on GEODE-7455:
--

Seen on support/1.13 in [distributed-test-openjdk11 
#11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/11]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/distributedTest/1639520684/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639520684/distributedtestfiles-openjdk11-1.13.6-build.0629.tgz].

> CI Failure: 
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
>  Failed
> --
>
> Key: GEODE-7455
> URL: https://issues.apache.org/jira/browse/GEODE-7455
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>  Labels: GeodeOperationAPI, flaky
>
> AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean
>  failed in DistributedTestOpenJDK11 below are the relevant details.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1280]
>  
> {noformat}
> 13:30:08
> org.apache.geode.management.AEQManagementDUnitTest > 
> testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean FAILED
> 13:30:08
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.AEQManagementDUnitTest$$Lambda$200/0x0008407dec40.run
>  in VM 0 running on Host 0e592392f6db with 4 VMs
> 13:30:08
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> 13:30:08
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> 13:30:08
> at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> 13:30:08
> at 
> org.apache.geode.management.AEQManagementDUnitTest.testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean(AEQManagementDUnitTest.java:245)
> 13:30:0813:30:08
> Caused by:
> 13:30:08
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 13:30:08
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 13:30:08
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 13:30:08
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 13:30:08
> at 
> org.apache.geode.management.AEQManagementDUnitTest.lambda$testCreateAEQWithDispatcherInPausedStateAndResumeAndVerifyUsingMBean$d4d42c35$1(AEQManagementDUnitTest.java:250)
> 14:10:3714:10:37
> 793 tests completed, 1 failed, 61 skipped {noformat}
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-results/distributedTest/1573687903/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0013/test-artifacts/1573687903/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0013.tgz



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9898) bump log4j to 2.16.0

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460238#comment-17460238
 ] 

Geode Integration commented on GEODE-9898:
--

Seen in [acceptance-test-openjdk8 
#57|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/57]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0739/test-results/acceptanceTest/1639519723/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0739/test-artifacts/1639519723/acceptancetestfiles-openjdk8-1.15.0-build.0739.tgz].

> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9898) bump log4j to 2.16.0

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460237#comment-17460237
 ] 

Geode Integration commented on GEODE-9898:
--

Seen on support/1.13 in [distributed-test-openjdk11 
#11|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk11/builds/11]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/distributedTest/1639520684/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639520684/distributedtestfiles-openjdk11-1.13.6-build.0629.tgz].

> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460235#comment-17460235
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#23|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/23]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639600279/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639600279/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.6
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460234#comment-17460234
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#23|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/23]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639600279/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639600279/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.6
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9502) Eliminate templates used to work around now-obsolete MSVC compiler warning

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460212#comment-17460212
 ] 

ASF GitHub Bot commented on GEODE-9502:
---

pivotal-jbarrett commented on a change in pull request #901:
URL: https://github.com/apache/geode-native/pull/901#discussion_r769982258



##
File path: cppcache/integration/framework/Cluster.cpp
##
@@ -146,7 +146,10 @@ void Locator::start() {
 }
 
 void Locator::stop() {
-  cluster_.getGfsh().stop().locator().withDir(name_).execute();
+  try {
+cluster_.getGfsh().stop().locator().withDir(name_).execute();
+  } catch (...) {

Review comment:
   Why are we eating exceptions in the teardown of the stopping of these 
components? If there is an exception that should affect the test. If the 
specific test wants to ignore the exceptions it would but it shouldn't be the 
default.




-- 
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


> Eliminate templates used to work around now-obsolete MSVC compiler warning
> --
>
> Key: GEODE-9502
> URL: https://issues.apache.org/jira/browse/GEODE-9502
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Blake Bender
>Priority: Major
>
> CacheableBuiltins.hpp contains the following comment, followed by a bunch of 
> very strange template definitions:
> // The following are defined as classes to avoid the issues with MSVC++
> // warning/erroring on C4503
> According to Microsoft 
> (https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4503?view=msvc-160),
>  this warning was obsolete as of VS2017.  We no longer support any pre-VS2017 
> compilers, so it should be safe to remove all this nonsense and replace it 
> with the template(s) originally intended.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9502) Eliminate templates used to work around now-obsolete MSVC compiler warning

[ASF GitHub Bot (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9502:
--
Labels: pull-request-available  (was: )

> Eliminate templates used to work around now-obsolete MSVC compiler warning
> --
>
> Key: GEODE-9502
> URL: https://issues.apache.org/jira/browse/GEODE-9502
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Blake Bender
>Priority: Major
>  Labels: pull-request-available
>
> CacheableBuiltins.hpp contains the following comment, followed by a bunch of 
> very strange template definitions:
> // The following are defined as classes to avoid the issues with MSVC++
> // warning/erroring on C4503
> According to Microsoft 
> (https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4503?view=msvc-160),
>  this warning was obsolete as of VS2017.  We no longer support any pre-VS2017 
> compilers, so it should be safe to remove all this nonsense and replace it 
> with the template(s) originally intended.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Dick Cavender (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dick Cavender updated GEODE-9901:
-
Affects Version/s: 1.13.6

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.6
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Dick Cavender (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Dick Cavender updated GEODE-9901:
-
Fix Version/s: (was: 1.13.6)

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test after Log4j 2.15 bump to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Summary: Failing upgrade-test after Log4j 2.15 bump to 2.16  (was: Failing 
upgrade-test after bump of Log4j 2.15 to 2.16)

> Failing upgrade-test after Log4j 2.15 bump to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Reporter: Steve Sienkowski
>Priority: Major
> Fix For: 1.13.6
>
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test after bump of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Summary: Failing upgrade-test after bump of Log4j 2.15 to 2.16  (was: 
Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16)

> Failing upgrade-test after bump of Log4j 2.15 to 2.16
> -
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Reporter: Steve Sienkowski
>Priority: Major
> Fix For: 1.13.6
>
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Fix Version/s: 1.13.6
   (was: 1.13.0)

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Reporter: Steve Sienkowski
>Priority: Major
> Fix For: 1.13.6
>
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Fix Version/s: 1.13.0
Affects Version/s: (was: 1.13.0)

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Reporter: Steve Sienkowski
>Priority: Major
> Fix For: 1.13.0
>
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Description: 
A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
pipeline.

These issues are characterized by an error message of 
`java.rmi.ConnectException: Connection refused to host:`

First failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]

Git commit introducing upgrade of log4j 2.15 to 2.16: 
[https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]

Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898

 

 

 

Example error message:

> Task :geode-gfsh:upgradeTest

org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] 
FAILED
    org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
c9ef3b85f95a with 4 VMs with version 1.12.0

        Caused by:
        java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
nested exception is: 
            java.net.ConnectException: Connection refused (Connection refused)

            Caused by:
            java.net.ConnectException: Connection refused (Connection refused)

  was:
A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
pipeline.

These issues are characterized by an error message of 
`java.rmi.ConnectException: Connection refused to host:`

First failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]

Git commit introducing upgrade of log4j 2.15 to 2.16: 
[https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]

 

Example error message:

> Task :geode-gfsh:upgradeTest

org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] 
FAILED
    org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
c9ef3b85f95a with 4 VMs with version 1.12.0

        Caused by:
        java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
nested exception is: 
            java.net.ConnectException: Connection refused (Connection refused)

            Caused by:
            java.net.ConnectException: Connection refused (Connection refused)


> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
> Relevant JIRA: https://issues.apache.org/jira/browse/GEODE-9898
>  
>  
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460175#comment-17460175
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#14|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639519709/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639519709/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460174#comment-17460174
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/16]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639528919/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639528919/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Sienkowski updated GEODE-9901:

Description: 
A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
pipeline.

These issues are characterized by an error message of 
`java.rmi.ConnectException: Connection refused to host:`

First failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]

Git commit introducing upgrade of log4j 2.15 to 2.16: 
[https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]

 

Example error message:

> Task :geode-gfsh:upgradeTest

org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] 
FAILED
    org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
c9ef3b85f95a with 4 VMs with version 1.12.0

        Caused by:
        java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
nested exception is: 
            java.net.ConnectException: Connection refused (Connection refused)

            Caused by:
            java.net.ConnectException: Connection refused (Connection refused)

  was:
A large number of tests are failing in the `upgrade-test-openjdk11` job of the 
1.13 pipeline.

These issues are characterized by an error message of 
`java.rmi.ConnectException: Connection refused to host:`

First failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]

Git commit introducing upgrade of log4j 2.15 to 2.16: 
[https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]

 

Example error message:

> Task :geode-gfsh:upgradeTest

org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] 
FAILED
    org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
c9ef3b85f95a with 4 VMs with version 1.12.0

        Caused by:
        java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
nested exception is: 
            java.net.ConnectException: Connection refused (Connection refused)

            Caused by:
            java.net.ConnectException: Connection refused (Connection refused)


> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460173#comment-17460173
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#16.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/16.1]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639534578/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639534578/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460172#comment-17460172
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#17|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/17]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639546899/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639546899/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A number of tests are failing in the `upgrade-test-openjdk11` job of the 1.13 
> pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460169#comment-17460169
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#22|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/22]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639576580/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639576580/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A large number of tests are failing in the `upgrade-test-openjdk11` job of 
> the 1.13 pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460171#comment-17460171
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#20|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/20]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639557036/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639557036/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A large number of tests are failing in the `upgrade-test-openjdk11` job of 
> the 1.13 pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460170#comment-17460170
 ] 

Geode Integration commented on GEODE-9901:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#21|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/21]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639565952/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639565952/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16
> --
>
> Key: GEODE-9901
> URL: https://issues.apache.org/jira/browse/GEODE-9901
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Steve Sienkowski
>Priority: Major
>
> A large number of tests are failing in the `upgrade-test-openjdk11` job of 
> the 1.13 pipeline.
> These issues are characterized by an error message of 
> `java.rmi.ConnectException: Connection refused to host:`
> First failure here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]
> Git commit introducing upgrade of log4j 2.15 to 2.16: 
> [https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]
>  
> Example error message:
> > Task :geode-gfsh:upgradeTest
> org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
> whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0]
>  FAILED
>     org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
> c9ef3b85f95a with 4 VMs with version 1.12.0
>         Caused by:
>         java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
> nested exception is: 
>             java.net.ConnectException: Connection refused (Connection refused)
>             Caused by:
>             java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-9901) Failing upgrade-test-openjdk11 after upgrade of Log4j 2.15 to 2.16

[Steve Sienkowski (Jira)]

Steve Sienkowski created GEODE-9901:
---

 Summary: Failing upgrade-test-openjdk11 after upgrade of Log4j 
2.15 to 2.16
 Key: GEODE-9901
 URL: https://issues.apache.org/jira/browse/GEODE-9901
 Project: Geode
  Issue Type: Bug
Affects Versions: 1.13.0
Reporter: Steve Sienkowski


A large number of tests are failing in the `upgrade-test-openjdk11` job of the 
1.13 pipeline.

These issues are characterized by an error message of 
`java.rmi.ConnectException: Connection refused to host:`

First failure here:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14]

Git commit introducing upgrade of log4j 2.15 to 2.16: 
[https://github.com/apache/geode/commit/224c996daa8bdd5243399e7d929120ad99c39fe3]

 

Example error message:

> Task :geode-gfsh:upgradeTest

org.apache.geode.management.GfshRebalanceCommandCompatibilityTest > 
whenCurrentVersionLocatorsExecuteRebalanceOnOldServersThenItMustSucceed[1.12.0] 
FAILED
    org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.IgnoredException$1.run in VM 0 running on Host 
c9ef3b85f95a with 4 VMs with version 1.12.0

        Caused by:
        java.rmi.ConnectException: Connection refused to host: 172.17.0.37; 
nested exception is: 
            java.net.ConnectException: Connection refused (Connection refused)

            Caused by:
            java.net.ConnectException: Connection refused (Connection refused)



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9899) Fix concurrency issue in RedisSet during GII

[ASF subversion and git services (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460146#comment-17460146
 ] 

ASF subversion and git services commented on GEODE-9899:


Commit da16195b670c177fe18c202a3bead277ef5df8de in geode's branch 
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=da16195 ]

GEODE-9899: Fix synchronization for RedisSet (#7201)

- This adds synchronization for methods where there is interaction
  between core Geode functionality and Radish operations. Specifically
  where `toData` may be called (during GII) and regular operations that
  mutate the underlying data structure in a `RedisSet`.


> Fix concurrency issue in RedisSet during GII
> 
>
> Key: GEODE-9899
> URL: https://issues.apache.org/jira/browse/GEODE-9899
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available, release-blocker
> Fix For: 1.15.0
>
>
> For the most part, access to Radish structures is performed through redis 
> commands and thus concurrent access is protected through the 
> {{{}StripedCoordinator{}}}. However access outside this protection can occur 
> directly through Geode internal flows. In particular, a GII process will 
> access the data structures via the {{toData}} and {{fromData}} calls. 
> Exceptions can occur if the structure is being modified and, at the same time 
> being read. For Example:
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>     at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>     at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.testConcurrency(RedisSetTest.java:350)
>     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.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>     at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
>     at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
>     at 
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
>     at org.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 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>     at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
>     at 
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:30)
>     at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
>     at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
>     at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NullPointerException
>     at 
> it.unimi.dsi.fastutil.objects.ObjectOpenCustomHashSet$SetIterator.next(ObjectOpenCustomHashSet.java:422)
>     at org.apache.geode.redis.internal.data.RedisSet.toData(RedisSet.java:211)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.iterateOverSet(RedisSetTest.java:368)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.lambda$testConcurrency$0(RedisSetTest.java:346)
>     at 
> 

[jira] [Resolved] (GEODE-9899) Fix concurrency issue in RedisSet during GII

[Jens Deppe (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jens Deppe resolved GEODE-9899.
---
Fix Version/s: 1.15.0
   Resolution: Fixed

> Fix concurrency issue in RedisSet during GII
> 
>
> Key: GEODE-9899
> URL: https://issues.apache.org/jira/browse/GEODE-9899
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
>  Labels: pull-request-available, release-blocker
> Fix For: 1.15.0
>
>
> For the most part, access to Radish structures is performed through redis 
> commands and thus concurrent access is protected through the 
> {{{}StripedCoordinator{}}}. However access outside this protection can occur 
> directly through Geode internal flows. In particular, a GII process will 
> access the data structures via the {{toData}} and {{fromData}} calls. 
> Exceptions can occur if the structure is being modified and, at the same time 
> being read. For Example:
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.NullPointerException
>     at java.util.concurrent.FutureTask.report(FutureTask.java:122)
>     at java.util.concurrent.FutureTask.get(FutureTask.java:192)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.testConcurrency(RedisSetTest.java:350)
>     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.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>     at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>     at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>     at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>     at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
>     at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
>     at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
>     at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
>     at 
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
>     at org.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 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
>     at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater$1.execute(IdeaTestRunner.java:38)
>     at 
> com.intellij.rt.execution.junit.TestsRepeater.repeat(TestsRepeater.java:30)
>     at 
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:35)
>     at 
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
>     at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: java.lang.NullPointerException
>     at 
> it.unimi.dsi.fastutil.objects.ObjectOpenCustomHashSet$SetIterator.next(ObjectOpenCustomHashSet.java:422)
>     at org.apache.geode.redis.internal.data.RedisSet.toData(RedisSet.java:211)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.iterateOverSet(RedisSetTest.java:368)
>     at 
> org.apache.geode.redis.internal.data.RedisSetTest.lambda$testConcurrency$0(RedisSetTest.java:346)
>     at 
> org.apache.geode.test.junit.rules.ExecutorServiceRule.lambda$submit$2(ExecutorServiceRule.java:263)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>     at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>     at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>     at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>     at 

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Anilkumar Gingade (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anilkumar Gingade updated GEODE-9900:
-
Component/s: security

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, security
>Affects Versions: 1.15.0
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Anilkumar Gingade (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anilkumar Gingade reassigned GEODE-9900:


Assignee: Joris Melchior

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.15.0
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Anilkumar Gingade (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anilkumar Gingade updated GEODE-9900:
-
Affects Version/s: 1.15.0

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.15.0
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9898) bump log4j to 2.16.0

[Geode Integration (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460100#comment-17460100
 ] 

Geode Integration commented on GEODE-9898:
--

Seen on support/1.13 in [upgrade-test-openjdk11 
#22|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/22]
 ... see [test 
results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-results/upgradeTest/1639576580/]
 or download 
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.6-build.0629/test-artifacts/1639576580/upgradetestfiles-openjdk11-1.13.6-build.0629.tgz].

> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9788) Develop PubSub Benchmark Tests

[ASF GitHub Bot (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460087#comment-17460087
 ] 

ASF GitHub Bot commented on GEODE-9788:
---

ezoerner commented on pull request #161:
URL: https://github.com/apache/geode-benchmarks/pull/161#issuecomment-994970599


   Good idea, I'll try that as a verification. I will also work on a new 
(smaller) pull request that does pattern matching on the channel names.


-- 
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


> Develop PubSub Benchmark Tests
> --
>
> Key: GEODE-9788
> URL: https://issues.apache.org/jira/browse/GEODE-9788
> Project: Geode
>  Issue Type: Test
>  Components: redis
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
>  Labels: pull-request-available
>
> Develop a suite of benchmarking tests for the pubsub API that benchmark the 
> comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of 
> the pubsub that allows us to monitor the performance over time and compared 
> to native Redis.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9898) bump log4j to 2.16.0

[Steve Sienkowski (Jira)]

[ 
https://issues.apache.org/jira/browse/GEODE-9898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460080#comment-17460080
 ] 

Steve Sienkowski commented on GEODE-9898:
-

It appears this bump from 2.15 to 2.16 has caused `apache-support-1-13-main` to 
fail.

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/upgrade-test-openjdk11/builds/14

> bump log4j to 2.16.0
> 
>
> Key: GEODE-9898
> URL: https://issues.apache.org/jira/browse/GEODE-9898
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.7, 1.13.6, 1.14.2, 1.15.0
>
>
> while the current jog4j 2.15.0 is sufficient to prevent CVE-2021-44228, 
> 2.16.0 is recommended as it fully disables jndi lookup 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Joris Melchior (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joris Melchior updated GEODE-9900:
--
Labels: GeodeOperationAPI needsTriage  (was: ne)

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Joris Melchior (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joris Melchior updated GEODE-9900:
--
Labels: ne  (was: )

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: ne
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9887) Deadlock when shutting down gws threads unnecessarily delay shutdown of server for 15 seconds

[Jakov Varenina (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jakov Varenina updated GEODE-9887:
--
Description: 
See deadlock in below logs:

1. "Distributed system shutdown hook" takes lock 0xc445e988, initiate 
"ConcurrentParallelGatewaySenderEventProcessor Stopper Thread" threads and 
waits for them to finish.

2. "ConcurrentParallelGatewaySenderEventProcessor Stopper Thread5" set flag 
AckReaderThread.shutdown to true and wait for shutdown to finish by joining 
threads for max 15 seconds.

3. "AckReaderThread for : Event Processor for GatewaySender_sender1_4" thread 
waits for the lock 0xc445e988 owned by "Distributed system shutdown 
hook"  thread

This deadlock only last for 15 seconds, because thread join will expire for all 
"ConcurrentParallelGatewaySenderEventProcessor Stopper Thread" threads forcing 
them to finish. After these threads finish then "Distributed system shutdown 
hook" can continue the execution, release the lock and conclude the shutdown of 
the server.

 
{code:java}
"Distributed system shutdown hook" #14 prio=5 os_prio=0 cpu=20.78ms 
elapsed=11.33s tid=0x7f848c005000 nid=0x1e04 waiting on condition  
[0x7f83ec415000]
   java.lang.Thread.State: WAITING (parking)
        at jdk.internal.misc.Unsafe.park(java.base@11.0.13/Native Method)
        - parking to wait for  <0xfcc00e50> (a 
java.util.concurrent.FutureTask)
        at 
java.util.concurrent.locks.LockSupport.park(java.base@11.0.13/LockSupport.java:194)
        at 
java.util.concurrent.FutureTask.awaitDone(java.base@11.0.13/FutureTask.java:447)
        at 
java.util.concurrent.FutureTask.get(java.base@11.0.13/FutureTask.java:190)
        at 
java.util.concurrent.AbstractExecutorService.invokeAll(java.base@11.0.13/AbstractExecutorService.java:247)
        at 
org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.stopProcessing(ConcurrentParallelGatewaySenderEventProcessor.java:258)
        at 
org.apache.geode.internal.cache.wan.AbstractGatewaySender.stopProcessing(AbstractGatewaySender.java:726)
        at 
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderImpl.stop(ParallelGatewaySenderImpl.java:118)
        at 
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2165)
        - locked <0xc11a7400> (a java.lang.Class for 
org.apache.geode.internal.cache.GemFireCacheImpl)
        at 
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1559)
        - locked <0xc11a7400> (a java.lang.Class for 
org.apache.geode.internal.cache.GemFireCacheImpl)
        at 
org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$7(InternalDistributedSystem.java:2202)
        at 
org.apache.geode.distributed.internal.InternalDistributedSystem$$Lambda$110/0x000100226840.run(Unknown
 Source)
        at java.lang.Thread.run(java.base@11.0.13/Thread.java:829)
   Locked ownable synchronizers:
        - <0xc445e988> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)



"AckReaderThread for : Event Processor for GatewaySender_sender1_4" #402 daemon 
prio=5 os_prio=0 cpu=3168.26ms elapsed=640.74s tid=0x7f8434023000 
nid=0x1181 waiting on condition  [0x7f83eda2b000]
   java.lang.Thread.State: WAITING (parking)
    at jdk.internal.misc.Unsafe.park(java.base@11.0.13/Native Method)
    - parking to wait for  <0xc445e988> (a 
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
    at 
java.util.concurrent.locks.LockSupport.park(java.base@11.0.13/LockSupport.java:194)
   at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.13/AbstractQueuedSynchronizer.java:885)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.13/AbstractQueuedSynchronizer.java:917)
    at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.13/AbstractQueuedSynchronizer.java:1240)
    at 
java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@11.0.13/ReentrantReadWriteLock.java:959)
    at 
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:665)
  Locked ownable synchronizers:
    - None




"ConcurrentParallelGatewaySenderEventProcessor Stopper Thread5" #872 daemon 
prio=5 os_prio=0 cpu=1.39ms elapsed=14.09s tid=0x7f849801a000 nid=0x1e13 in 
Object.wait()  [0x7f849c442000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
        at java.lang.Object.wait(java.base@11.0.13/Native Method)
        - waiting on 
        at java.lang.Thread.join(java.base@11.0.13/Thread.java:1308)
        - waiting to re-lock in wait() <0xc542ce20> (a 

[jira] [Updated] (GEODE-9887) Deadlock when shutting down gws threads unnecessarily delay shutdown of server for 15 seconds

[Jakov Varenina (Jira)]

 [ 
https://issues.apache.org/jira/browse/GEODE-9887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jakov Varenina updated GEODE-9887:
--
Summary: Deadlock when shutting down gws threads unnecessarily delay 
shutdown of server for 15 seconds  (was: Deadlock when shutting down gws 
threads unecessary delay shutdown of server)

> Deadlock when shutting down gws threads unnecessarily delay shutdown of 
> server for 15 seconds
> -
>
> Key: GEODE-9887
> URL: https://issues.apache.org/jira/browse/GEODE-9887
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>  Labels: pull-request-available
>
> See deadlock in below logs:
> 1. "Distributed system shutdown hook" takes lock 0xc445e988, initiate 
> "ConcurrentParallelGatewaySenderEventProcessor Stopper Thread" threads and 
> waits for them to finish.
> 2. "ConcurrentParallelGatewaySenderEventProcessor Stopper Thread5" set flag 
> AckReaderThread.shutdown to true and wait for shutdown to finish by joining 
> threads for max 15 seconds.
> 3. "AckReaderThread for : Event Processor for GatewaySender_sender1_4" thread 
> waits for the lock 0xc445e988 owned by "Distributed system shutdown 
> hook"  thread
>  
> {code:java}
> "Distributed system shutdown hook" #14 prio=5 os_prio=0 cpu=20.78ms 
> elapsed=11.33s tid=0x7f848c005000 nid=0x1e04 waiting on condition  
> [0x7f83ec415000]
>    java.lang.Thread.State: WAITING (parking)
>         at jdk.internal.misc.Unsafe.park(java.base@11.0.13/Native Method)
>         - parking to wait for  <0xfcc00e50> (a 
> java.util.concurrent.FutureTask)
>         at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.13/LockSupport.java:194)
>         at 
> java.util.concurrent.FutureTask.awaitDone(java.base@11.0.13/FutureTask.java:447)
>         at 
> java.util.concurrent.FutureTask.get(java.base@11.0.13/FutureTask.java:190)
>         at 
> java.util.concurrent.AbstractExecutorService.invokeAll(java.base@11.0.13/AbstractExecutorService.java:247)
>         at 
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.stopProcessing(ConcurrentParallelGatewaySenderEventProcessor.java:258)
>         at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySender.stopProcessing(AbstractGatewaySender.java:726)
>         at 
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderImpl.stop(ParallelGatewaySenderImpl.java:118)
>         at 
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2165)
>         - locked <0xc11a7400> (a java.lang.Class for 
> org.apache.geode.internal.cache.GemFireCacheImpl)
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1559)
>         - locked <0xc11a7400> (a java.lang.Class for 
> org.apache.geode.internal.cache.GemFireCacheImpl)
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.lambda$static$7(InternalDistributedSystem.java:2202)
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem$$Lambda$110/0x000100226840.run(Unknown
>  Source)
>         at java.lang.Thread.run(java.base@11.0.13/Thread.java:829)
>    Locked ownable synchronizers:
>         - <0xc445e988> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
> "AckReaderThread for : Event Processor for GatewaySender_sender1_4" #402 
> daemon prio=5 os_prio=0 cpu=3168.26ms elapsed=640.74s tid=0x7f8434023000 
> nid=0x1181 waiting on condition  [0x7f83eda2b000]
>    java.lang.Thread.State: WAITING (parking)
>     at jdk.internal.misc.Unsafe.park(java.base@11.0.13/Native Method)
>     - parking to wait for  <0xc445e988> (a 
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
>     at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.13/LockSupport.java:194)
>    at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.13/AbstractQueuedSynchronizer.java:885)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.13/AbstractQueuedSynchronizer.java:917)
>     at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.13/AbstractQueuedSynchronizer.java:1240)
>     at 
> java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@11.0.13/ReentrantReadWriteLock.java:959)
>     at 
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher$AckReaderThread.run(GatewaySenderEventRemoteDispatcher.java:665)
>   Locked ownable synchronizers:
>     - None
>