[jira] [Created] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
Benjamin P Ross created GEODE-10093: --- Summary: DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value Key: GEODE-10093 URL: https://issues.apache.org/jira/browse/GEODE-10093 Project: Geode Issue Type: Bug Components: http session Affects Versions: 1.14.3, 1.13.7, 1.12.7, 1.15.0 Reporter: Benjamin P Ross Under certain circumstances, a null value can be set for an attribute which then throws an NPE when trying to add it to the local map during a getAttribute call on the session. Prior to 1.12.2 we were responding to this by removing the entry entirely from the local map which is consistent with what the base Session class for Catalina does, but starting with 1.12.2 onward this results in an error message being displayed and the serialized value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10093) DeltaSession getAttribute method logs an NPE and returns unserialized value when called on attribute with null value
[ https://issues.apache.org/jira/browse/GEODE-10093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-10093: --- Assignee: Benjamin P Ross > DeltaSession getAttribute method logs an NPE and returns unserialized value > when called on attribute with null value > > > Key: GEODE-10093 > URL: https://issues.apache.org/jira/browse/GEODE-10093 > Project: Geode > Issue Type: Bug > Components: http session >Affects Versions: 1.12.7, 1.13.7, 1.14.3, 1.15.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Labels: needsTriage > > Under certain circumstances, a null value can be set for an attribute which > then throws an NPE when trying to add it to the local map during a > getAttribute call on the session. Prior to 1.12.2 we were responding to this > by removing the entry entirely from the local map which is consistent with > what the base Session class for Catalina does, but starting with 1.12.2 > onward this results in an error message being displayed and the serialized > value being returned rather than the unserialized value. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9737) CI failure in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
[
https://issues.apache.org/jira/browse/GEODE-9737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17483413#comment-17483413
]
Benjamin P Ross commented on GEODE-9737:
I've removed the release blocker tags from this issue based on things I've
learned while investigating the issue. The first reason is that there is
evidence that this issue can occur in earlier product versions (it's possible
that [GEODE-5121|https://issues.apache.org/jira/browse/GEODE-5121] is the same
issue and there were local reproductions of what looks like the same issue
going back to 1.13) which suggests this issue was likely introduced before this
release. The second reason is that the use case for the test in question is
testing a condition which only applies to a user upgrading their version of the
Tomcat7 module. Since Tomcat7 is essentially unused in favor of Tomcat8 or
Tomcat9 modules it is unlikely a user would ever experience this use case. On
top of both these things, the failure itself seems likely to be specifically
related to the containers used for the test and so far attempts to recreate the
failure outside of the cargo containers used for the test haven't reproduced
the issue, suggesting this is probably a test issue anyway and not a product
issue.
> CI failure in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> --
>
> Key: GEODE-9737
> URL: https://issues.apache.org/jira/browse/GEODE-9737
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Attachments: gemfire.log
>
>
> {noformat}
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> > test[0] FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
> TOMCAT7_client-server_test0_1_dd13a1a6-effb-4430-8ccd-ee6c9142938c_
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:82)
> at
> org.apache.geode.session.tests.ContainerManager.startContainers(ContainerManager.java:93)
> at
> org.apache.geode.session.tests.ContainerManager.startAllInactiveContainers(ContainerManager.java:101)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.doPutAndGetSessionOnAllClients(TomcatSessionBackwardsCompatibilityTestBase.java:187)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.test(TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.java:36)
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:220)
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:79)
> ... 4 more
> Caused by:
> org.codehaus.cargo.container.ContainerException: Deployable
> [http://localhost:26322/cargocpc/index.html] failed to finish deploying
> within the timeout period [12]. The Deployable state is thus unknown.
> at
> org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:387)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:234)
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:218)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9737) CI failure in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
[
https://issues.apache.org/jira/browse/GEODE-9737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9737:
---
Labels: (was: blocks-1.15.0 release-blocker)
> CI failure in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> --
>
> Key: GEODE-9737
> URL: https://issues.apache.org/jira/browse/GEODE-9737
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Attachments: gemfire.log
>
>
> {noformat}
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> > test[0] FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
> TOMCAT7_client-server_test0_1_dd13a1a6-effb-4430-8ccd-ee6c9142938c_
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:82)
> at
> org.apache.geode.session.tests.ContainerManager.startContainers(ContainerManager.java:93)
> at
> org.apache.geode.session.tests.ContainerManager.startAllInactiveContainers(ContainerManager.java:101)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.doPutAndGetSessionOnAllClients(TomcatSessionBackwardsCompatibilityTestBase.java:187)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.test(TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.java:36)
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:220)
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:79)
> ... 4 more
> Caused by:
> org.codehaus.cargo.container.ContainerException: Deployable
> [http://localhost:26322/cargocpc/index.html] failed to finish deploying
> within the timeout period [12]. The Deployable state is thus unknown.
> at
> org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:387)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:234)
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:218)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9737) CI failure in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
[
https://issues.apache.org/jira/browse/GEODE-9737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9737:
---
Attachment: gemfire.log
> CI failure in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> --
>
> Key: GEODE-9737
> URL: https://issues.apache.org/jira/browse/GEODE-9737
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Attachments: gemfire.log
>
>
> {noformat}
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> > test[0] FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
> TOMCAT7_client-server_test0_1_dd13a1a6-effb-4430-8ccd-ee6c9142938c_
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:82)
> at
> org.apache.geode.session.tests.ContainerManager.startContainers(ContainerManager.java:93)
> at
> org.apache.geode.session.tests.ContainerManager.startAllInactiveContainers(ContainerManager.java:101)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.doPutAndGetSessionOnAllClients(TomcatSessionBackwardsCompatibilityTestBase.java:187)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.test(TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.java:36)
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:220)
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:79)
> ... 4 more
> Caused by:
> org.codehaus.cargo.container.ContainerException: Deployable
> [http://localhost:26322/cargocpc/index.html] failed to finish deploying
> within the timeout period [12]. The Deployable state is thus unknown.
> at
> org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:387)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:234)
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:218)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9737) CI failure in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
[
https://issues.apache.org/jira/browse/GEODE-9737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9737:
---
Labels: (was: needsTriage)
This issue seems to be a test issue with the gemfire cluster starting in the
container rather than a product issue. The underlying cause is that the locator
of the cluster is unavailable when the client/servers try to connect to it
within the container (see attached gemfire log)
> CI failure in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> --
>
> Key: GEODE-9737
> URL: https://issues.apache.org/jira/browse/GEODE-9737
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
>
> {noformat}
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest
> > test[0] FAILED
> java.lang.RuntimeException: Something very bad happened when trying to
> start container
> TOMCAT7_client-server_test0_1_dd13a1a6-effb-4430-8ccd-ee6c9142938c_
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:82)
> at
> org.apache.geode.session.tests.ContainerManager.startContainers(ContainerManager.java:93)
> at
> org.apache.geode.session.tests.ContainerManager.startAllInactiveContainers(ContainerManager.java:101)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTestBase.doPutAndGetSessionOnAllClients(TomcatSessionBackwardsCompatibilityTestBase.java:187)
> at
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.test(TomcatSessionBackwardsCompatibilityTomcat7079WithOldModulesMixedWithCurrentCanDoPutFromCurrentModuleTest.java:36)
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this
> container when starting. Check the cargo_logs folder for container logs.
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:220)
> at
> org.apache.geode.session.tests.ContainerManager.startContainer(ContainerManager.java:79)
> ... 4 more
> Caused by:
> org.codehaus.cargo.container.ContainerException: Deployable
> [http://localhost:26322/cargocpc/index.html] failed to finish deploying
> within the timeout period [12]. The Deployable state is thus unknown.
> at
> org.codehaus.cargo.container.spi.deployer.DeployerWatchdog.watch(DeployerWatchdog.java:111)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.waitForCompletion(AbstractLocalContainer.java:387)
> at
> org.codehaus.cargo.container.spi.AbstractLocalContainer.start(AbstractLocalContainer.java:234)
> at
> org.apache.geode.session.tests.ServerContainer.start(ServerContainer.java:218)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9790) CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest. testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived fails due to TimeoutExceptio
[
https://issues.apache.org/jira/browse/GEODE-9790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9790:
---
Description:
We've seen this test fail in CI with the following stack trace:
{code:java}
ParallelWANPersistenceEnabledGatewaySenderDUnitTest >
testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
FAILED
java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed out
waiting 30 milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueuesInVMsAsync(WANTestBase.java:1100)
at
org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived(ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java:1780)
Caused by:
java.util.concurrent.TimeoutException: Timed out waiting 30
milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
... 2 more
Caused by:
org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
vm-4 thread-33
at java.lang.Thread.sleep(Native Method)
at
org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10057)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:570)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:447)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:281)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:250)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.initializeMessageQueue(ParallelGatewaySenderEventProcessor.java:80)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.(ParallelGatewaySenderEventProcessor.java:65)
at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.(RemoteParallelGatewaySenderEventProcessor.java:39)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.createProcessors(RemoteConcurrentParallelGatewaySenderEventProcessor.java:50)
at
org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.(ConcurrentParallelGatewaySenderEventProcessor.java:102)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.(RemoteConcurrentParallelGatewaySenderEventProcessor.java:38)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.start(ParallelGatewaySenderImpl.java:86)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.startWithCleanQueue(ParallelGatewaySenderImpl.java:61)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueues(WANTestBase.java:1134)
at
org.apache.geode.internal.cache.wan.WANTestBase.lambda$startSenderwithCleanQueuesInVMsAsync$1527b440$1(WANTestBase.java:1096)
at
org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$456/976167913.run(Unknown
Source)
at
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
at sun.reflect.GeneratedMethodAccessor309.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at
[jira] [Updated] (GEODE-9790) CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest. testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived fails due to TimeoutExceptio
[
https://issues.apache.org/jira/browse/GEODE-9790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9790:
---
Description:
We've seen this test fail in CI with the following stack trace:
{code:java}
ParallelWANPersistenceEnabledGatewaySenderDUnitTest >
testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
FAILED
java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed out
waiting 30 milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueuesInVMsAsync(WANTestBase.java:1100)
at
org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived(ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java:1780)
Caused by:
java.util.concurrent.TimeoutException: Timed out waiting 30
milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
... 2 more
Caused by:
org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
vm-4 thread-33
at java.lang.Thread.sleep(Native Method)
at
org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10057)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:570)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:447)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:281)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:250)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.initializeMessageQueue(ParallelGatewaySenderEventProcessor.java:80)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.(ParallelGatewaySenderEventProcessor.java:65)
at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.(RemoteParallelGatewaySenderEventProcessor.java:39)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.createProcessors(RemoteConcurrentParallelGatewaySenderEventProcessor.java:50)
at
org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.(ConcurrentParallelGatewaySenderEventProcessor.java:102)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.(RemoteConcurrentParallelGatewaySenderEventProcessor.java:38)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.start(ParallelGatewaySenderImpl.java:86)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.startWithCleanQueue(ParallelGatewaySenderImpl.java:61)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueues(WANTestBase.java:1134)
at
org.apache.geode.internal.cache.wan.WANTestBase.lambda$startSenderwithCleanQueuesInVMsAsync$1527b440$1(WANTestBase.java:1096)
at
org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$456/976167913.run(Unknown
Source)
at
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
at sun.reflect.GeneratedMethodAccessor309.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at
[jira] [Updated] (GEODE-9790) CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest. testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived fails due to TimeoutExceptio
[
https://issues.apache.org/jira/browse/GEODE-9790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9790:
---
Affects Version/s: (was: 1.15.0)
> CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest.
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> fails due to TimeoutException while restarting senders
>
>
> Key: GEODE-9790
> URL: https://issues.apache.org/jira/browse/GEODE-9790
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Benjamin P Ross
>Priority: Major
> Labels: needsTriage
>
> We've seen this test fail in CI with the following stack trace:
> {code:java}
> ParallelWANPersistenceEnabledGatewaySenderDUnitTest >
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed
> out waiting 30 milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueuesInVMsAsync(WANTestBase.java:1100)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived(ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java:1780)
> Caused by:
> java.util.concurrent.TimeoutException: Timed out waiting 30
> milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
> ... 2 more
> Caused by:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
> vm-4 thread-33
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10057)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:570)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:447)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:281)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:250)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.initializeMessageQueue(ParallelGatewaySenderEventProcessor.java:80)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.(ParallelGatewaySenderEventProcessor.java:65)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.(RemoteParallelGatewaySenderEventProcessor.java:39)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.createProcessors(RemoteConcurrentParallelGatewaySenderEventProcessor.java:50)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.(ConcurrentParallelGatewaySenderEventProcessor.java:102)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.(RemoteConcurrentParallelGatewaySenderEventProcessor.java:38)
> at
> org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.start(ParallelGatewaySenderImpl.java:86)
> at
> org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.startWithCleanQueue(ParallelGatewaySenderImpl.java:61)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueues(WANTestBase.java:1134)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.lambda$startSenderwithCleanQueuesInVMsAsync$1527b440$1(WANTestBase.java:1096)
> at
> org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$456/976167913.run(Unknown
> Source)
> at
>
[jira] [Updated] (GEODE-9790) CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest. testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived fails due to TimeoutExceptio
[
https://issues.apache.org/jira/browse/GEODE-9790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-9790:
---
Labels: (was: needsTriage)
> CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest.
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> fails due to TimeoutException while restarting senders
>
>
> Key: GEODE-9790
> URL: https://issues.apache.org/jira/browse/GEODE-9790
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Benjamin P Ross
>Priority: Major
>
> We've seen this test fail in CI with the following stack trace:
> {code:java}
> ParallelWANPersistenceEnabledGatewaySenderDUnitTest >
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed
> out waiting 30 milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueuesInVMsAsync(WANTestBase.java:1100)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived(ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java:1780)
> Caused by:
> java.util.concurrent.TimeoutException: Timed out waiting 30
> milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
> ... 2 more
> Caused by:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
> vm-4 thread-33
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10057)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:570)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:447)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:281)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:250)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.initializeMessageQueue(ParallelGatewaySenderEventProcessor.java:80)
> at
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.(ParallelGatewaySenderEventProcessor.java:65)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.(RemoteParallelGatewaySenderEventProcessor.java:39)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.createProcessors(RemoteConcurrentParallelGatewaySenderEventProcessor.java:50)
> at
> org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.(ConcurrentParallelGatewaySenderEventProcessor.java:102)
> at
> org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.(RemoteConcurrentParallelGatewaySenderEventProcessor.java:38)
> at
> org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.start(ParallelGatewaySenderImpl.java:86)
> at
> org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.startWithCleanQueue(ParallelGatewaySenderImpl.java:61)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueues(WANTestBase.java:1134)
> at
> org.apache.geode.internal.cache.wan.WANTestBase.lambda$startSenderwithCleanQueuesInVMsAsync$1527b440$1(WANTestBase.java:1096)
> at
> org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$456/976167913.run(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
> at
[jira] [Created] (GEODE-9790) CI Failure: ParallelWANPersistenceEnabledGatewaySenderDUnitTest. testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived fails due to TimeoutExceptio
Benjamin P Ross created GEODE-9790:
--
Summary: CI Failure:
ParallelWANPersistenceEnabledGatewaySenderDUnitTest.
testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
fails due to TimeoutException while restarting senders
Key: GEODE-9790
URL: https://issues.apache.org/jira/browse/GEODE-9790
Project: Geode
Issue Type: Bug
Components: wan
Affects Versions: 1.15.0
Reporter: Benjamin P Ross
We've seen this test fail in CI with the following stack trace:
{code:java}
ParallelWANPersistenceEnabledGatewaySenderDUnitTest >
testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
FAILED
java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed out
waiting 30 milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueuesInVMsAsync(WANTestBase.java:1100)
at
org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived(ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java:1780)
Caused by:
java.util.concurrent.TimeoutException: Timed out waiting 30
milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
... 2 more
Caused by:
org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
vm-4 thread-33
at java.lang.Thread.sleep(Native Method)
at
org.apache.geode.internal.cache.PartitionedRegion.shadowPRWaitForBucketRecovery(PartitionedRegion.java:10057)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:570)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.addShadowPartitionedRegionForUserPR(ParallelGatewaySenderQueue.java:447)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:281)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue.(ParallelGatewaySenderQueue.java:250)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.initializeMessageQueue(ParallelGatewaySenderEventProcessor.java:80)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderEventProcessor.(ParallelGatewaySenderEventProcessor.java:65)
at
org.apache.geode.cache.wan.internal.parallel.RemoteParallelGatewaySenderEventProcessor.(RemoteParallelGatewaySenderEventProcessor.java:39)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.createProcessors(RemoteConcurrentParallelGatewaySenderEventProcessor.java:50)
at
org.apache.geode.internal.cache.wan.parallel.ConcurrentParallelGatewaySenderEventProcessor.(ConcurrentParallelGatewaySenderEventProcessor.java:102)
at
org.apache.geode.cache.wan.internal.parallel.RemoteConcurrentParallelGatewaySenderEventProcessor.(RemoteConcurrentParallelGatewaySenderEventProcessor.java:38)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.start(ParallelGatewaySenderImpl.java:86)
at
org.apache.geode.cache.wan.internal.parallel.ParallelGatewaySenderImpl.startWithCleanQueue(ParallelGatewaySenderImpl.java:61)
at
org.apache.geode.internal.cache.wan.WANTestBase.startSenderwithCleanQueues(WANTestBase.java:1134)
at
org.apache.geode.internal.cache.wan.WANTestBase.lambda$startSenderwithCleanQueuesInVMsAsync$1527b440$1(WANTestBase.java:1096)
at
org.apache.geode.internal.cache.wan.WANTestBase$$Lambda$456/976167913.run(Unknown
Source)
at
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run(IdentifiableRunnable.java:41)
at sun.reflect.GeneratedMethodAccessor309.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
at
org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
at
[jira] [Created] (GEODE-9606) CI Failure: PubSubIntegrationTest.testPatternWithoutAGlob fails with AssertionError
Benjamin P Ross created GEODE-9606: -- Summary: CI Failure: PubSubIntegrationTest.testPatternWithoutAGlob fails with AssertionError Key: GEODE-9606 URL: https://issues.apache.org/jira/browse/GEODE-9606 Project: Geode Issue Type: Bug Components: redis Affects Versions: 1.15.0 Reporter: Benjamin P Ross The following failure occurred in a CI run: org.apache.geode.redis.internal.executor.pubsub.PubSubIntegrationTest > testPatternWithoutAGlob FAILED java.lang.AssertionError: Expecting actual: [] to contain exactly (and in same order): ["hello"] but could not find the following elements: ["hello"] at org.apache.geode.redis.internal.executor.pubsub.AbstractPubSubIntegrationTest.testPatternWithoutAGlob(AbstractPubSubIntegrationTest.java:774) 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.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119) at 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)
[jira] [Commented] (GEODE-9530) CI Failure: ClassNotFoundException in TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
[
https://issues.apache.org/jira/browse/GEODE-9530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17403947#comment-17403947
]
Benjamin P Ross commented on GEODE-9530:
So far trying to recreate this locally has failed, so it could be a
test/pipeline issue. I will try reverting to the commit that originally
reproduced it as well to see if any chances made since effected it.
> CI Failure: ClassNotFoundException in
> TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> -
>
> Key: GEODE-9530
> URL: https://issues.apache.org/jira/browse/GEODE-9530
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: blocks-1.14.0
>
> {noformat}
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> > initializationError FAILED
> java.lang.ClassNotFoundException:
> org.apache.geode.session.tests.TomcatSessionBackwardsCompatibilityTomcat7079WithOldModuleCanDoPutsTest
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:67)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
> at
> org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-14-main/1.14.0-build.0770/test-results/upgradeTest/1619235491/
>
[jira] [Resolved] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross resolved GEODE-8990.
Resolution: Fixed
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9106) CI Failure: Client Server Session Cache fails infrequently with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-9106. Resolution: Duplicate > CI Failure: Client Server Session Cache fails infrequently with > ConditionTimeoutException > - > > Key: GEODE-9106 > URL: https://issues.apache.org/jira/browse/GEODE-9106 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest > > preCreatedRegionIsNotCopiedToNewlyStartedServers FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$52/487544699.run > in VM 1 running on Host a1dde695db62 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.preCreatedRegionIsNotCopiedToNewlyStartedServers(ClientServerSessionCacheDUnitTest.java:144) > Caused by: > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest > Expected size: 1 but was: 0 in: > [] within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > 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:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$preCreatedRegionIsNotCopiedToNewlyStartedServers$bb17a952$1(ClientServerSessionCacheDUnitTest.java:144) > Caused by: > java.lang.AssertionError: > Expected size: 1 but was: 0 in: > [] > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258) > This issue seems to be specific to the method validateBootstrapped(). In this > method we attempt to verify that the BootstrappingFunction is being > registered as a Listener within the Distribution Manager (which is a part of > setting up the ClientServerSessionCache) however in some situations it seems > that we are unable to verify this. This issue does not seem to reproduce > locally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross resolved GEODE-8990.
Fix Version/s: 1.15.0
Resolution: Fixed
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9116) CI Failure: ParallelWANStatsDUnitTest fails when checking that batches with incomplete transactions should be 0
Benjamin P Ross created GEODE-9116: -- Summary: CI Failure: ParallelWANStatsDUnitTest fails when checking that batches with incomplete transactions should be 0 Key: GEODE-9116 URL: https://issues.apache.org/jira/browse/GEODE-9116 Project: Geode Issue Type: Bug Affects Versions: 1.15.0 Reporter: Benjamin P Ross org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest > testPRParallelPropagationWithGroupTransactionEventsDoesNotSendBatchesWithIncompleteTransactionsIfGatewaySenderIsStoppedWhileReceivingTrafficAndLaterStarted FAILED java.lang.AssertionError: expected:<0> but was:<1> at org.junit.Assert.fail(Assert.java:89) at org.junit.Assert.failNotEquals(Assert.java:835) at org.junit.Assert.assertEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:633) at org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.checkOnlyCompleteTransactionsAreReplicatedAfterSenderStopped(ParallelWANStatsDUnitTest.java:611) at org.apache.geode.internal.cache.wan.parallel.ParallelWANStatsDUnitTest.testPRParallelPropagationWithGroupTransactionEventsDoesNotSendBatchesWithIncompleteTransactionsIfGatewaySenderIsStoppedWhileReceivingTrafficAndLaterStarted(ParallelWANStatsDUnitTest.java:520) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9106) CI Failure: Client Server Session Cache fails infrequently with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-9106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-9106: -- Assignee: Benjamin P Ross > CI Failure: Client Server Session Cache fails infrequently with > ConditionTimeoutException > - > > Key: GEODE-9106 > URL: https://issues.apache.org/jira/browse/GEODE-9106 > Project: Geode > Issue Type: Bug >Affects Versions: 1.14.0 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest > > preCreatedRegionIsNotCopiedToNewlyStartedServers FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$52/487544699.run > in VM 1 running on Host a1dde695db62 with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) > at org.apache.geode.test.dunit.VM.invoke(VM.java:448) > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.preCreatedRegionIsNotCopiedToNewlyStartedServers(ClientServerSessionCacheDUnitTest.java:144) > Caused by: > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest > Expected size: 1 but was: 0 in: > [] within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) > 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:895) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$preCreatedRegionIsNotCopiedToNewlyStartedServers$bb17a952$1(ClientServerSessionCacheDUnitTest.java:144) > Caused by: > java.lang.AssertionError: > Expected size: 1 but was: 0 in: > [] > at > org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258) > This issue seems to be specific to the method validateBootstrapped(). In this > method we attempt to verify that the BootstrappingFunction is being > registered as a Listener within the Distribution Manager (which is a part of > setting up the ClientServerSessionCache) however in some situations it seems > that we are unable to verify this. This issue does not seem to reproduce > locally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9106) CI Failure: Client Server Session Cache fails infrequently with ConditionTimeoutException
Benjamin P Ross created GEODE-9106: -- Summary: CI Failure: Client Server Session Cache fails infrequently with ConditionTimeoutException Key: GEODE-9106 URL: https://issues.apache.org/jira/browse/GEODE-9106 Project: Geode Issue Type: Bug Affects Versions: 1.14.0 Reporter: Benjamin P Ross org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest > preCreatedRegionIsNotCopiedToNewlyStartedServers FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest$$Lambda$52/487544699.run in VM 1 running on Host a1dde695db62 with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) at org.apache.geode.test.dunit.VM.invoke(VM.java:448) at org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.preCreatedRegionIsNotCopiedToNewlyStartedServers(ClientServerSessionCacheDUnitTest.java:144) Caused by: org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest Expected size: 1 but was: 0 in: [] within 5 minutes. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165) 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:895) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679) at org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.lambda$preCreatedRegionIsNotCopiedToNewlyStartedServers$bb17a952$1(ClientServerSessionCacheDUnitTest.java:144) Caused by: java.lang.AssertionError: Expected size: 1 but was: 0 in: [] at org.apache.geode.modules.util.ClientServerSessionCacheDUnitTest.validateBootstrapped(ClientServerSessionCacheDUnitTest.java:258) This issue seems to be specific to the method validateBootstrapped(). In this method we attempt to verify that the BootstrappingFunction is being registered as a Listener within the Distribution Manager (which is a part of setting up the ClientServerSessionCache) however in some situations it seems that we are unable to verify this. This issue does not seem to reproduce locally. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8969) CI Failure: TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException fails with EOFException
[
https://issues.apache.org/jira/browse/GEODE-8969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290167#comment-17290167
]
Benjamin P Ross commented on GEODE-8969:
Although there have been many failures with this error message in the past,
GEODE-7948 looks like it could be a similar issue as they are both testing
Internet Protocols.
> CI Failure: TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException
> fails with EOFException
> -
>
> Key: GEODE-8969
> URL: https://issues.apache.org/jira/browse/GEODE-8969
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.13.2
>Reporter: Benjamin P Ross
>Priority: Major
>
> {code:java}
> // Some comments here
> java.io.EOFException: Locator at HostAndPort[/10.0.0.13:50126] did not
> respond. This is normal if the locator was shutdown. If it wasn't check its
> log for exceptions.
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:202)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:133)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException(TcpServerJUnitTest.java:183)
> 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:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
>
[jira] [Created] (GEODE-8969) CI Failure: TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException fails with EOFException
Benjamin P Ross created GEODE-8969:
--
Summary: CI Failure:
TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException fails with
EOFException
Key: GEODE-8969
URL: https://issues.apache.org/jira/browse/GEODE-8969
Project: Geode
Issue Type: Bug
Affects Versions: 1.13.2
Reporter: Benjamin P Ross
{code:java}
// Some comments here
java.io.EOFException: Locator at HostAndPort[/10.0.0.13:50126] did not respond.
This is normal if the locator was shutdown. If it wasn't check its log for
exceptions.
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:202)
at
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:133)
at
org.apache.geode.distributed.internal.tcpserver.TcpServerJUnitTest.testNewConnectionsAcceptedAfterSocketException(TcpServerJUnitTest.java:183)
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:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at
org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
at
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
[jira] [Commented] (GEODE-8392) CI Failure: Jetty9CachingClientServerTest > sessionPicksUpSessionTimeoutConfiguredInWebXml
[ https://issues.apache.org/jira/browse/GEODE-8392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290148#comment-17290148 ] Benjamin P Ross commented on GEODE-8392: We saw this failure again on 1.13 (http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.2-build.0463/test-results/distributedTest/1612351073/classes/org.apache.geode.session.tests.Tomcat9CachingClientServerTest.html#sessionPicksUpSessionTimeoutConfiguredInWebXml), this time with the Tomcat9CachingClientServerTest. It's likely this issue is with the CargoTestBase. > CI Failure: Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml > -- > > Key: GEODE-8392 > URL: https://issues.apache.org/jira/browse/GEODE-8392 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Owen Nichols >Priority: Major > > Failure: [DistributedTestOpenJDK11 > #381|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/381#A] > org.apache.geode.session.tests.Jetty9CachingClientServerTest > > sessionPicksUpSessionTimeoutConfiguredInWebXml FAILED > org.awaitility.core.ConditionTimeoutException: Condition with lambda > expression in org.apache.geode.session.tests.CargoTestBase was not fulfilled > within 5 minutes. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-results/distributedTest/1596061367/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0247/test-artifacts/1596061367/distributedtestfiles-OpenJDK11-1.14.0-build.0247.tgz*] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6872) Add section with more details about sticky vs non-sticky sessions for Tomcat Session Module
[ https://issues.apache.org/jira/browse/GEODE-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-6872. Resolution: Done > Add section with more details about sticky vs non-sticky sessions for Tomcat > Session Module > --- > > Key: GEODE-6872 > URL: https://issues.apache.org/jira/browse/GEODE-6872 > Project: Geode > Issue Type: Bug > Components: docs, http session >Reporter: Ryan McMahon >Priority: Major > Labels: GeodeCommons > > Sticky vs non-sticky sessions and the recommended configurations should be > discussed in better detail the docs (it is not discussed at all for Tomcat > module). If the user configured client-server topology with non-sticky > sessions, we do NOT recommend enableLocalCaching be set because it results in > unpredictable asynchronous behavior/replication. > If they follow our recommendations and disable local caching (proxy-only > client), then they should also set `gemfire.EXPIRE_SENDS_ENTRY_AS_CALLBACK`. > Otherwise the expire logic will not be called on the client. The side effects > of this may be benign, but if there are any listeners depending on that > expiration logic, it may result in bugs or a resource leak. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross resolved GEODE-6867.
Resolution: Done
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some required jars
> # Need to indicate that a locator MUST be available for peer-to-peer topology
> More details on both issues below:
> We should review the session state documentation for
> completeness/correctness. When attempting to install and configure the
> Tomcat and AppServer session modules by following the docs, I found that
> there were missing jars in the [installation
> section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]
> for Tomcat and [setting up
> section|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]
> for AppServer. Namely, I had to add these missing jars (as of 9.8, maybe
> earlier).
> * micrometer-core jar
> * geode-commons jar
> * geode-management jar
> The first is a new jar added since this documentation was written, and I'm
> assuming the code was restructured to require the other two jars as
> dependencies. I'm not sure how we can ensure that this list is up to date.
> Some of our system level tests for session state have to include the same
> list. From TomcatInstall.java:
> {code:java}
> private static final String[] tomcatRequiredJars =
> {"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
> "geode-common",
> "geode-core", "geode-management", "javax.transaction-api", "jgroups",
> "log4j-api",
> "log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
> "jetty-util",
> "jetty-http", "jetty-io"};{code}
> And you can see that this list was updated to make the tests pass when
> dependencies changed.
> The other major issue I found while running through the steps is that you
> MUST start a locator in the peer-to-peer topology for session state, because
> multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6874) Improve Unit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-6874. Resolution: Done > Improve Unit test coverage for Tomcat session state module > -- > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-7846. Resolution: Fixed > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
Benjamin P Ross created GEODE-8644: -- Summary: 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 Reporter: Benjamin P Ross Currently the test SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() relies on a 2 second delay to allow for queues to finish draining after finishing the put operation. If queues take longer than 2 seconds to drain the test will fail. We should change the test to wait for the queues to be empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-8644: -- Assignee: Benjamin P Ross > 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 >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
[
https://issues.apache.org/jira/browse/GEODE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17202302#comment-17202302
]
Benjamin P Ross commented on GEODE-8411:
Saw this again in a CI run.
> CI Failure: Jetty9CachingClientServerTest.
> containersShouldShareDataRemovals() fails with comparison failure
>
>
> Key: GEODE-8411
> URL: https://issues.apache.org/jira/browse/GEODE-8411
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI
> run.
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldShareDataRemovals FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8528) PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to missing disk store after server restart
[ https://issues.apache.org/jira/browse/GEODE-8528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17201755#comment-17201755 ] Benjamin P Ross commented on GEODE-8528: I attempted to replicate this both locally and in the cloud, but wasn't able to reproduce it after a significant number of runs. It's possible that this failure was due to an environment issue with the disk the test was running on or that this is a very rare flaky failure caused by the tests unique method of shutting down server 2. I don't think it is related to GEODE-8353 as I had originally speculated. > PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to > missing disk store after server restart > -- > > Key: GEODE-8528 > URL: https://issues.apache.org/jira/browse/GEODE-8528 > Project: Geode > Issue Type: Bug >Affects Versions: 1.12.0 >Reporter: Benjamin P Ross >Priority: Major > > org.apache.geode.internal.cache.PutAllClientServerDistributedTest > > testPartialKeyInPRSingleHop FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$313/839097690.call > in VM 1 running on Host 3e9ce4ee92bd with 4 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) > at org.apache.geode.test.dunit.VM.invoke(VM.java:462) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop(PutAllClientServerDistributedTest.java:1894) > Caused by: > java.lang.IllegalStateException: Disk store ds1 not found > at > org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7480) > at > org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRegion.java:9203) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:602) > at > org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:546) > at > org.apache.geode.internal.cache.PartitionedRegion.(PartitionedRegion.java:760) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2925) > at > org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2869) > at > org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2853) > at > org.apache.geode.cache.RegionFactory.create(RegionFactory.java:768) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.createServer(PutAllClientServerDistributedTest.java:2797) > at > org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPartialKeyInPRSingleHop$515fd116$1(PutAllClientServerDistributedTest.java:1894) > Halfway through the test we shutdown Server2 and restart it, but upon > attempting to start the server with the same disk store name we used original > we get missing disk store errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8528) PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to missing disk store after server restart
Benjamin P Ross created GEODE-8528: -- Summary: PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop fails due to missing disk store after server restart Key: GEODE-8528 URL: https://issues.apache.org/jira/browse/GEODE-8528 Project: Geode Issue Type: Bug Affects Versions: 1.12.0 Reporter: Benjamin P Ross org.apache.geode.internal.cache.PutAllClientServerDistributedTest > testPartialKeyInPRSingleHop FAILED org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$313/839097690.call in VM 1 running on Host 3e9ce4ee92bd with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) at org.apache.geode.test.dunit.VM.invoke(VM.java:462) at org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPartialKeyInPRSingleHop(PutAllClientServerDistributedTest.java:1894) Caused by: java.lang.IllegalStateException: Disk store ds1 not found at org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7480) at org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRegion.java:9203) at org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:602) at org.apache.geode.internal.cache.LocalRegion.(LocalRegion.java:546) at org.apache.geode.internal.cache.PartitionedRegion.(PartitionedRegion.java:760) at org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2925) at org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2869) at org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2853) at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:768) at org.apache.geode.internal.cache.PutAllClientServerDistributedTest.createServer(PutAllClientServerDistributedTest.java:2797) at org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPartialKeyInPRSingleHop$515fd116$1(PutAllClientServerDistributedTest.java:1894) Halfway through the test we shutdown Server2 and restart it, but upon attempting to start the server with the same disk store name we used original we get missing disk store errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8526) CI Failure: RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy fails due to suspicous string (RejectedExecutionException)
Benjamin P Ross created GEODE-8526:
--
Summary: CI Failure:
RestAPIsWithSSLDUnitTest.testWithMultipleProtocolLegacy fails due to suspicous
string (RejectedExecutionException)
Key: GEODE-8526
URL: https://issues.apache.org/jira/browse/GEODE-8526
Project: Geode
Issue Type: Bug
Affects Versions: 1.12.0
Reporter: Benjamin P Ross
{code:java}
org.apache.geode.rest.internal.web.controllers.RestAPIsWithSSLDUnitTest >
testWithMultipleProtocolLegacy FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2058
[fatal 2020/09/04 08:48:48.497 GMT
tid=1198] Uncaught exception in thread Thread[Geode Failure Detection thread
2,5,RMI Runtime]
java.util.concurrent.RejectedExecutionException: Task
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$5835/0x0001050d4040@4431b231
rejected from java.util.concurrent.ThreadPoolExecutor@13324d3[Shutting down,
pool size = 1, active threads = 1, queued tasks = 0, completed tasks = 2]
at
java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
at
java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
at
java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1296)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1232)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1480)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:479)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:463)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17193186#comment-17193186
]
Benjamin P Ross edited comment on GEODE-8191 at 9/9/20, 9:29 PM:
-
Recently saw this failure again on develop:
{code:java}
org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in
org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but
was:<[375]0> within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
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:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at
org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108)
Caused by:
org.junit.ComparisonFailure: expected:<[400]0> but was:<[375]0>
at
jdk.internal.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:113)
{code}
Since this flakey failure is still happening I'm reopening the ticket,
[~mivanac].
was (Author: sarm kahel):
Recently saw this failure again on develop:
{code:java}
org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in
org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but
was:<[375]0> within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
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:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at
org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108)
Caused by:
org.junit.ComparisonFailure: expected:<[400]0> but was:<[375]0>
at
jdk.internal.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:113)
{code}
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.14.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
>
[jira] [Reopened] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross reopened GEODE-8191:
Recently saw this failure again on develop:
{code:java}
org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in
org.apache.geode.management.MemberMXBeanDistributedTest expected:<[400]0> but
was:<[375]0> within 5 minutes.
at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
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:895)
at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
at
org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:108)
Caused by:
org.junit.ComparisonFailure: expected:<[400]0> but was:<[375]0>
at
jdk.internal.reflect.GeneratedConstructorAccessor33.newInstance(Unknown Source)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:113)
{code}
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
> Fix For: 1.14.0
>
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 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:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
Benjamin P Ross created GEODE-8411:
--
Summary: CI Failure: Jetty9CachingClientServerTest.
containersShouldShareDataRemovals() fails with comparison failure
Key: GEODE-8411
URL: https://issues.apache.org/jira/browse/GEODE-8411
Project: Geode
Issue Type: Bug
Reporter: Benjamin P Ross
We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI run.
{code:java}
org.apache.geode.session.tests.Jetty9CachingClientServerTest >
containersShouldShareDataRemovals FAILED
org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-7846: -- Assignee: Benjamin P Ross > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7671) Partitioned Region clear operations can occur successfully during GII
[ https://issues.apache.org/jira/browse/GEODE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-7671: -- Assignee: Benjamin P Ross > Partitioned Region clear operations can occur successfully during GII > -- > > Key: GEODE-7671 > URL: https://issues.apache.org/jira/browse/GEODE-7671 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Clear operations are successful when the region is undergoing GII > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region when they are undergoing GII from another member > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8074) Add documentation for PR clear
[ https://issues.apache.org/jira/browse/GEODE-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-8074: --- Description: With the addition of the ability to clear a partitioned region we need to add documentation for the following: * new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) * changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) * existing documentation for clear to indicate clearing a partitioned region is permitted. was: With the addition of the ability to clear a partitioned region we need to add documentation for the following: * new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) *changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) *existing documentation for clear to indicate clearing a partitioned region is permitted. > Add documentation for PR clear > -- > > Key: GEODE-8074 > URL: https://issues.apache.org/jira/browse/GEODE-8074 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Benjamin P Ross >Priority: Major > > With the addition of the ability to clear a partitioned region we need to add > documentation for the following: > * new gfsh command 'clear' and modifications made to existing 'remove' > command (work done on GEODE-7667) > * changed the clearCount stat in 'cachePerfStats' to regionClearCount and > bucketClearCount in addition to adding localClearDuration and > TotalClearDuration stats (work done on GEODE-7846) > * existing documentation for clear to indicate clearing a partitioned region > is permitted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8074) Add documentation for PR clear
[ https://issues.apache.org/jira/browse/GEODE-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-8074: --- Description: With the addition of the ability to clear a partitioned region we need to add documentation for the following: * new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) *changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) *existing documentation for clear to indicate clearing a partitioned region is permitted. was: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) - changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) - existing documentation for clear to indicate clearing a partitioned region is permitted. > Add documentation for PR clear > -- > > Key: GEODE-8074 > URL: https://issues.apache.org/jira/browse/GEODE-8074 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Benjamin P Ross >Priority: Major > > With the addition of the ability to clear a partitioned region we need to add > documentation for the following: > * new gfsh command 'clear' and modifications made to existing 'remove' > command (work done on GEODE-7667) > *changed the clearCount stat in 'cachePerfStats' to regionClearCount and > bucketClearCount in addition to adding localClearDuration and > TotalClearDuration stats (work done on GEODE-7846) > *existing documentation for clear to indicate clearing a partitioned region > is permitted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8074) Add documentation for PR clear
[ https://issues.apache.org/jira/browse/GEODE-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-8074: --- Description: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) - changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) - existing documentation for clear to indicate clearing a partitioned region is permitted. was: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) - changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) - existing documentation for clear to indicate clearing a partitioned region is permitted. > Add documentation for PR clear > -- > > Key: GEODE-8074 > URL: https://issues.apache.org/jira/browse/GEODE-8074 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Benjamin P Ross >Priority: Major > > With the addition of the ability to clear a partitioned region we need to add > documentation for the following: > - new gfsh command 'clear' and modifications made to existing 'remove' > command (work done on GEODE-7667) > > - changed the clearCount stat in 'cachePerfStats' to regionClearCount and > bucketClearCount in addition to adding localClearDuration and > TotalClearDuration stats (work done on GEODE-7846) > - existing documentation for clear to indicate clearing a partitioned region > is permitted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8074) Add documentation for PR clear
[ https://issues.apache.org/jira/browse/GEODE-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-8074: --- Description: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' and modifications made to existing 'remove' command (work done on GEODE-7667) - changed the clearCount stat in 'cachePerfStats' to regionClearCount and bucketClearCount in addition to adding localClearDuration and TotalClearDuration stats (work done on GEODE-7846) - existing documentation for clear to indicate clearing a partitioned region is permitted. was: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' (work done on GEODE- - as well as update existing documentation for existing clear feature and 'remove' command. > Add documentation for PR clear > -- > > Key: GEODE-8074 > URL: https://issues.apache.org/jira/browse/GEODE-8074 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Benjamin P Ross >Priority: Major > > With the addition of the ability to clear a partitioned region we need to add > documentation for the following: > - new gfsh command 'clear' and modifications made to existing 'remove' > command (work done on GEODE-7667) > - changed the clearCount stat in 'cachePerfStats' to regionClearCount and > bucketClearCount in addition to adding localClearDuration and > TotalClearDuration stats (work done on GEODE-7846) > - existing documentation for clear to indicate clearing a partitioned region > is permitted. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8074) Add documentation for PR clear
[ https://issues.apache.org/jira/browse/GEODE-8074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-8074: --- Description: With the addition of the ability to clear a partitioned region we need to add documentation for the following: - new gfsh command 'clear' (work done on GEODE- - as well as update existing documentation for existing clear feature and 'remove' command. was:With the addition of the ability to clear a partitioned region we need to add documentation for the new gfsh command 'clear' as well as update existing documentation for existing clear feature and 'remove' command. > Add documentation for PR clear > -- > > Key: GEODE-8074 > URL: https://issues.apache.org/jira/browse/GEODE-8074 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Benjamin P Ross >Priority: Major > > With the addition of the ability to clear a partitioned region we need to add > documentation for the following: > - new gfsh command 'clear' (work done on GEODE- > - as well as update existing documentation for existing clear feature and > 'remove' command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7846) Clear in Partitioned Region should have its own stats
[ https://issues.apache.org/jira/browse/GEODE-7846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7846: --- Labels: GeodeCommons GeodeOperationAPI pull-request-available (was: GeodeCommons pull-request-available) > Clear in Partitioned Region should have its own stats > - > > Key: GEODE-7846 > URL: https://issues.apache.org/jira/browse/GEODE-7846 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Clear operation in PR should have its own stats: > 1) clear operation executed. > 2) clear operation failed > 3) clear messages sends to buckets -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8074) Add documentation for PR clear
Benjamin P Ross created GEODE-8074: -- Summary: Add documentation for PR clear Key: GEODE-8074 URL: https://issues.apache.org/jira/browse/GEODE-8074 Project: Geode Issue Type: New Feature Components: docs Reporter: Benjamin P Ross With the addition of the ability to clear a partitioned region we need to add documentation for the new gfsh command 'clear' as well as update existing documentation for existing clear feature and 'remove' command. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
[
https://issues.apache.org/jira/browse/GEODE-8021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-8021:
---
Description:
{code:java}
org.apache.geode.internal.tcp.CloseConnectionTest >
sharedSenderShouldRecoverFromClosedSocket FAILED
16:25:33org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in
VM 1 running on Host 0f261f07755e with 4 VMs
16:25:33at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
16:25:33at
org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
16:25:33
16:25:33Caused by:
16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
16:25:33at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
16:25:33at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
16:25:33at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
16:25:33at
org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
18:30:47
{code}
was:org.apache.geode.internal.tcp.CloseConnectionTest >
sharedSenderShouldRecoverFromClosedSocket FAILED 16:25:33
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in
VM 1 running on Host 0f261f07755e with 4 VMs 16:25:33 at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) 16:25:33 at
org.apache.geode.test.dunit.VM.invoke(VM.java:437) 16:25:33 at
org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
16:25:33 16:25:33 Caused by: 16:25:33 org.junit.ComparisonFailure:
expected:<[tru]e> but was:<[fals]e> 16:25:33 at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 16:25:33
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
16:25:33 at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
16:25:33 at
org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
18:30:47
> CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
> --
>
> Key: GEODE-8021
> URL: https://issues.apache.org/jira/browse/GEODE-8021
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.tcp.CloseConnectionTest >
> sharedSenderShouldRecoverFromClosedSocket FAILED
> 16:25:33org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run
> in VM 1 running on Host 0f261f07755e with 4 VMs
> 16:25:33at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 16:25:33at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102)
> 16:25:33
> 16:25:33Caused by:
> 16:25:33org.junit.ComparisonFailure: expected:<[tru]e> but
> was:<[fals]e>
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 16:25:33at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 16:25:33at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 16:25:33at
> org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109)
> 18:30:47
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8021) CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket
Benjamin P Ross created GEODE-8021: -- Summary: CI Failure: CloseConnectionTest. sharedSenderShouldRecoverFromClosedSocket Key: GEODE-8021 URL: https://issues.apache.org/jira/browse/GEODE-8021 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross org.apache.geode.internal.tcp.CloseConnectionTest > sharedSenderShouldRecoverFromClosedSocket FAILED 16:25:33 org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.internal.tcp.CloseConnectionTest$$Lambda$36/1787754664.run in VM 1 running on Host 0f261f07755e with 4 VMs 16:25:33 at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610) 16:25:33 at org.apache.geode.test.dunit.VM.invoke(VM.java:437) 16:25:33 at org.apache.geode.internal.tcp.CloseConnectionTest.sharedSenderShouldRecoverFromClosedSocket(CloseConnectionTest.java:102) 16:25:33 16:25:33 Caused by: 16:25:33 org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> 16:25:33 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) 16:25:33 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) 16:25:33 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) 16:25:33 at org.apache.geode.internal.tcp.CloseConnectionTest.lambda$sharedSenderShouldRecoverFromClosedSocket$bb17a952$6(CloseConnectionTest.java:109) 18:30:47 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7667) GFSH commands - uniform gfsh command to clear regions
[ https://issues.apache.org/jira/browse/GEODE-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-7667: -- Assignee: Benjamin P Ross > GFSH commands - uniform gfsh command to clear regions > - > > Key: GEODE-7667 > URL: https://issues.apache.org/jira/browse/GEODE-7667 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons, docs > Time Spent: 2h 50m > Remaining Estimate: 0h > > * Currently, the gfsh command to clear replicated region is called ‘remove > —region=/regionName’. > * Replace this command with ‘clear region —region=regionName’ > * While executing this gfsh command on partitioned regions, this should call > the clear() Java API using the gfsh function execution machinery. > * Point to note is that this command should take into consideration of the > coordinator selection and how this command is distributed to the members > Acceptance : > * There should be ‘clear region —region=/regionName’ gfsh command > * DUnit tests to verify that command can be executed successfully on > PartitionedRegion > * Deprecate the remove command, as remove does not mean clear > * Unit tests with complete code coverage for the newly written code. > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7667) GFSH commands - uniform gfsh command to clear regions
[ https://issues.apache.org/jira/browse/GEODE-7667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7667: --- Description: * Currently, the gfsh command to clear replicated region is called ‘remove —region=/regionName’. * Replace this command with ‘clear region —region=regionName’ * While executing this gfsh command on partitioned regions, this should call the clear() Java API using the gfsh function execution machinery. * Point to note is that this command should take into consideration of the coordinator selection and how this command is distributed to the members Acceptance : * There should be ‘clear region —region=/regionName’ gfsh command * DUnit tests to verify that command can be executed successfully on PartitionedRegion * Deprecate the remove command, as remove does not mean clear * Unit tests with complete code coverage for the newly written code. * Test coverage to when a member departs in this scenario * Test coverage to when a member restarts in this scenario was: * Currently, the gfsh command to clear replicated region is called ‘remove —region=/regionName’. * Replace this command with ‘clear —region=regionName’ * While executing this gfsh command on partitioned regions, this should call the clear() Java API using the gfsh function execution machinery. * Point to note is that this command should take into consideration of the coordinator selection and how this command is distributed to the members Acceptance : * There should be ‘clear —region=/regionName’ gfsh command * DUnit tests to verify that command can be executed successfully on PartitionedRegion * Deprecate the remove command, as remove does not mean clear * Unit tests with complete code coverage for the newly written code. * Test coverage to when a member departs in this scenario * Test coverage to when a member restarts in this scenario > GFSH commands - uniform gfsh command to clear regions > - > > Key: GEODE-7667 > URL: https://issues.apache.org/jira/browse/GEODE-7667 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons, docs > Time Spent: 2h 50m > Remaining Estimate: 0h > > * Currently, the gfsh command to clear replicated region is called ‘remove > —region=/regionName’. > * Replace this command with ‘clear region —region=regionName’ > * While executing this gfsh command on partitioned regions, this should call > the clear() Java API using the gfsh function execution machinery. > * Point to note is that this command should take into consideration of the > coordinator selection and how this command is distributed to the members > Acceptance : > * There should be ‘clear region —region=/regionName’ gfsh command > * DUnit tests to verify that command can be executed successfully on > PartitionedRegion > * Deprecate the remove command, as remove does not mean clear > * Unit tests with complete code coverage for the newly written code. > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7368) EntryNotFoundExceptions are thrown when sessions are evicted during unload
[ https://issues.apache.org/jira/browse/GEODE-7368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-7368. Fix Version/s: 1.12.0 Resolution: Fixed > EntryNotFoundExceptions are thrown when sessions are evicted during unload > -- > > Key: GEODE-7368 > URL: https://issues.apache.org/jira/browse/GEODE-7368 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Benjamin P Ross >Priority: Major > Fix For: 1.12.0 > > Time Spent: 20m > Remaining Estimate: 0h > > During the unload process (DeltaSessionManager) we write our current sessions > to disk and delete them from our session region. It's possible for a session > to be evicted while this process is ongoing which results in an EntryNotFound > exception which interrupts the process of clearing out the region. > We can fix this by catching the exception and ignoring it - there is no > circumstance where we want to change behavior if an entry is evicted right as > we go to delete it in this process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7753) CI Failure: Tomcat9CachingClientServerTest. multipleClientsCanMaintainOwnSessions
Benjamin P Ross created GEODE-7753: -- Summary: CI Failure: Tomcat9CachingClientServerTest. multipleClientsCanMaintainOwnSessions Key: GEODE-7753 URL: https://issues.apache.org/jira/browse/GEODE-7753 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross We saw a failure in CI for this test: org.apache.geode.session.tests.Tomcat9CachingClientServerTest > multipleClientsCanMaintainOwnSessions FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but was:<"[]"> within 300 seconds. Caused by: org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> java.lang.NullPointerException org.apache.geode.session.tests.Tomcat6CachingClientServerTest > multipleClientsCanMaintainOwnSessions FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but was:<"[]"> within 300 seconds. Caused by: org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> java.lang.NullPointerException org.apache.geode.session.tests.Tomcat7CachingClientServerTest > multipleClientsCanMaintainOwnSessions FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but was:<"[]"> within 300 seconds. Caused by: org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.session.tests.CargoTestBase expected:<"[Foo55]"> but was:<"[]"> within 300 seconds. Caused by: org.junit.ComparisonFailure: expected:<"[Foo55]"> but was:<"[]"> java.lang.NullPointerException java.lang.NullPointerException It's possible that this issue could show up in Tomcat 7,8, and 9 tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6107) CI Failure: org.apache.geode.management.JMXMBeanReconnectDUnitTest > testRemoteBeanKnowledge_MaintainServerAndCrashLocator
[
https://issues.apache.org/jira/browse/GEODE-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002968#comment-17002968
]
Benjamin P Ross commented on GEODE-6107:
Another CI failure:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1433]
I agree with Owen, if we know that this test fails because of a product issue
we should either leave this story open or have a different story to track the
known issue.
> CI Failure: org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator
> --
>
> Key: GEODE-6107
> URL: https://issues.apache.org/jira/browse/GEODE-6107
> Project: Geode
> Issue Type: Bug
>Reporter: Ryan McMahon
>Assignee: Helena Bales
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/172
> Results:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.210/test-results/distributedTest/1543449109/
> Artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.210/test-artifacts/1543449109/distributedtestfiles-OpenJDK8-1.9.0-build.210.tgz
> {noformat}org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with alias
> 'Locators must agree on the state of the system' didn't complete within 300
> seconds because assertion condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest
> Expecting:
> <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
> GemFire:service=FileUploader,type=Distributed,
> GemFire:service=System,type=Distributed,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one,
> GemFire:service=Locator,type=Member,member=locator-one,
> GemFire:type=Member,member=locator-one,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-two,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-two,
> GemFire:service=Locator,type=Member,member=locator-two,
> GemFire:type=Member,member=locator-two,
>
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> GemFire:service=CacheServer,port=33929,type=Member,member=server-2,
> GemFire:type=Member,member=server-2,
>
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> GemFire:service=CacheServer,port=46497,type=Member,member=server-3,
> GemFire:type=Member,member=server-3]>
> to contain exactly (and in same order):
> <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
> GemFire:service=FileUploader,type=Distributed,
> GemFire:service=System,type=Distributed,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one,
> GemFire:service=Locator,type=Member,member=locator-one,
> GemFire:type=Member,member=locator-one,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-two,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-two,
> GemFire:service=Locator,type=Member,member=locator-two,
> GemFire:type=Member,member=locator-two,
>
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> GemFire:service=CacheServer,port=33929,type=Member,member=server-2,
> GemFire:type=Member,member=server-2,
>
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> GemFire:service=CacheServer,port=46497,type=Member,member=server-3,
> GemFire:type=Member,member=server-3]>
> but some elements were not expected:
>
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one]>
> .
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
>
[jira] [Comment Edited] (GEODE-7622) CI Failure: JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002967#comment-17002967
]
Benjamin P Ross edited comment on GEODE-7622 at 12/24/19 7:00 PM:
--
Resolving this issue since it's a duplicate of
https://issues.apache.org/jira/browse/GEODE-6107
was (Author: sarm kahel):
Resolving this issue since it's a duplicate of
https://issues.apache.org/jira/browse/GEODE-7106
> CI Failure:
> JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails
> with ConditionTimeoutException
>
>
> Key: GEODE-7622
> URL: https://issues.apache.org/jira/browse/GEODE-7622
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
>
> We've seen JMXMBeanReconnectDUnitTest fail intermittently with
> {code:java}
> org.awaitility.core.ConditionTimeoutException: Condition with alias 'Locators
> must agree on the state of the system' didn't complete within 300 seconds
> because assertion condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest
> 18:26:35Expecting:
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35to contain exactly (and in same order):
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35but some elements were not expected:
> 18:26:35
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0]>
> 18:26:35.
> 18:26:35at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 18:26:35at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 18:26:35at
>
[jira] [Commented] (GEODE-7622) CI Failure: JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17002967#comment-17002967
]
Benjamin P Ross commented on GEODE-7622:
Resolving this issue since it's a duplicate of
https://issues.apache.org/jira/browse/GEODE-7106
> CI Failure:
> JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails
> with ConditionTimeoutException
>
>
> Key: GEODE-7622
> URL: https://issues.apache.org/jira/browse/GEODE-7622
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
>
> We've seen JMXMBeanReconnectDUnitTest fail intermittently with
> {code:java}
> org.awaitility.core.ConditionTimeoutException: Condition with alias 'Locators
> must agree on the state of the system' didn't complete within 300 seconds
> because assertion condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest
> 18:26:35Expecting:
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35to contain exactly (and in same order):
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35but some elements were not expected:
> 18:26:35
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0]>
> 18:26:35.
> 18:26:35at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 18:26:35at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 18:26:35at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 18:26:35at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.before(JMXMBeanReconnectDUnitTest.java:94)
> 18:26:35
> 18:26:35
[jira] [Resolved] (GEODE-7622) CI Failure: JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails with ConditionTimeoutException
[
https://issues.apache.org/jira/browse/GEODE-7622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross resolved GEODE-7622.
Resolution: Duplicate
> CI Failure:
> JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails
> with ConditionTimeoutException
>
>
> Key: GEODE-7622
> URL: https://issues.apache.org/jira/browse/GEODE-7622
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
>
> We've seen JMXMBeanReconnectDUnitTest fail intermittently with
> {code:java}
> org.awaitility.core.ConditionTimeoutException: Condition with alias 'Locators
> must agree on the state of the system' didn't complete within 300 seconds
> because assertion condition defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest
> 18:26:35Expecting:
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35to contain exactly (and in same order):
> 18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> 18:26:35GemFire:service=AccessControl,type=Distributed,
> 18:26:35GemFire:service=FileUploader,type=Distributed,
> 18:26:35GemFire:service=System,type=Distributed,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-0,
> 18:26:35GemFire:type=Member,member=locator-0,
> 18:26:35
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
> 18:26:35GemFire:service=Locator,type=Member,member=locator-1,
> 18:26:35GemFire:type=Member,member=locator-1,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> 18:26:35
> GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
> 18:26:35GemFire:type=Member,member=server-2,
> 18:26:35
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> 18:26:35
> GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
> 18:26:35GemFire:type=Member,member=server-3]>
> 18:26:35but some elements were not expected:
> 18:26:35
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
> 18:26:35
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0]>
> 18:26:35.
> 18:26:35at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> 18:26:35at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> 18:26:35at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> 18:26:35at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> 18:26:35at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.before(JMXMBeanReconnectDUnitTest.java:94)
> 18:26:35
> 18:26:35Caused by:
> 18:26:35java.lang.AssertionError:
> 18:26:35Expecting:
> 18:26:35
>
[jira] [Created] (GEODE-7622) CI Failure: JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails with ConditionTimeoutException
Benjamin P Ross created GEODE-7622:
--
Summary: CI Failure:
JMXMBeanReconnectDUnitTest.testLocalBeans_MaintainLocatorAndCrashServer fails
with ConditionTimeoutException
Key: GEODE-7622
URL: https://issues.apache.org/jira/browse/GEODE-7622
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Benjamin P Ross
We've seen JMXMBeanReconnectDUnitTest fail intermittently with
{code:java}
org.awaitility.core.ConditionTimeoutException: Condition with alias 'Locators
must agree on the state of the system' didn't complete within 300 seconds
because assertion condition defined as a lambda expression in
org.apache.geode.management.JMXMBeanReconnectDUnitTest
18:26:35Expecting:
18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
18:26:35GemFire:service=AccessControl,type=Distributed,
18:26:35GemFire:service=FileUploader,type=Distributed,
18:26:35GemFire:service=System,type=Distributed,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
18:26:35
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0,
18:26:35GemFire:service=Locator,type=Member,member=locator-0,
18:26:35GemFire:type=Member,member=locator-0,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
18:26:35
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
18:26:35GemFire:service=Locator,type=Member,member=locator-1,
18:26:35GemFire:type=Member,member=locator-1,
18:26:35
GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
18:26:35
GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
18:26:35GemFire:type=Member,member=server-2,
18:26:35
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
18:26:35
GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
18:26:35GemFire:type=Member,member=server-3]>
18:26:35to contain exactly (and in same order):
18:26:35 <[GemFire:service=Region,name="/test-region-1",type=Distributed,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
18:26:35GemFire:service=AccessControl,type=Distributed,
18:26:35GemFire:service=FileUploader,type=Distributed,
18:26:35GemFire:service=System,type=Distributed,
18:26:35GemFire:service=Locator,type=Member,member=locator-0,
18:26:35GemFire:type=Member,member=locator-0,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-1,
18:26:35
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-1,
18:26:35GemFire:service=Locator,type=Member,member=locator-1,
18:26:35GemFire:type=Member,member=locator-1,
18:26:35
GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
18:26:35
GemFire:service=CacheServer,port=35679,type=Member,member=server-2,
18:26:35GemFire:type=Member,member=server-2,
18:26:35
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
18:26:35
GemFire:service=CacheServer,port=44573,type=Member,member=server-3,
18:26:35GemFire:type=Member,member=server-3]>
18:26:35but some elements were not expected:
18:26:35
<[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
18:26:35
GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-0]>
18:26:35.
18:26:35at
org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
18:26:35at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
18:26:35at
org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
18:26:35at
org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
18:26:35at
org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
18:26:35at
org.apache.geode.management.JMXMBeanReconnectDUnitTest.before(JMXMBeanReconnectDUnitTest.java:94)
18:26:35
18:26:35Caused by:
18:26:35java.lang.AssertionError:
18:26:35Expecting:
18:26:35
<[GemFire:service=Region,name="/test-region-1",type=Distributed,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
18:26:35GemFire:service=AccessControl,type=Distributed,
18:26:35GemFire:service=FileUploader,type=Distributed,
18:26:35GemFire:service=System,type=Distributed,
18:26:35
GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-0,
18:26:35
[jira] [Created] (GEODE-7621) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion. luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion fails wit
Benjamin P Ross created GEODE-7621:
--
Summary: CI Failure:
RollingUpgradeQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion.
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion fails
with DSFIDNotFoundException
Key: GEODE-7621
URL: https://issues.apache.org/jira/browse/GEODE-7621
Project: Geode
Issue Type: Bug
Components: tests
Reporter: Benjamin P Ross
We've seen
luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion fail
intermittently with:
{code:java}
error 2019/12/23 22:05:05.434 GMT tid=49]
Exception deserializing message payload: [dst: 172.17.0.8:32772, src:
172.17.0.8:41002 (2 headers), size=105 bytes,
flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]error 2019/12/23 22:05:05.434 GMT
tid=49] Exception deserializing message
payload: [dst: 172.17.0.8:32772, src: 172.17.0.8:41002 (2 headers),
size=105 bytes, flags=OOB|DONT_BUNDLE|NO_FC|SKIP_BARRIER]
org.apache.geode.internal.DSFIDNotFoundException: Unknown
DataSerializableFixedID: -158 at
org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:998) at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.deserializeMessage(JGroupsMessenger.java:1118)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.readJGMessage(JGroupsMessenger.java:1010)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1276)
at org.jgroups.JChannel.invokeCallback(JChannel.java:816) at
org.jgroups.JChannel.up(JChannel.java:741) at
org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030) at
org.jgroups.protocols.FRAG2.up(FRAG2.java:165) at
org.jgroups.protocols.FlowControl.up(FlowControl.java:390) at
org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070) at
org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785) at
org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426) at
org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:74)
at
org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1601) at
org.jgroups.protocols.TP$SingleMessageHandler.run(TP.java:1817) at
org.jgroups.util.DirectExecutor.execute(DirectExecutor.java:10) at
org.jgroups.protocols.TP.handleSingleMessage(TP.java:1729) at
org.jgroups.protocols.TP.receive(TP.java:1654) at
org.apache.geode.distributed.internal.membership.gms.messenger.Transport.receive(Transport.java:160)
at org.jgroups.protocols.UDP$PacketReceiver.run(UDP.java:701) at
java.base/java.lang.Thread.run(Thread.java:834){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7598) CI Failure: Assertion failure during ResourceManagerWithQueryMonitorDUnitTest
Benjamin P Ross created GEODE-7598: -- Summary: CI Failure: Assertion failure during ResourceManagerWithQueryMonitorDUnitTest Key: GEODE-7598 URL: https://issues.apache.org/jira/browse/GEODE-7598 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1411 There doesn't seem to be a directly related commit recently before the change so It might be a flaky failure caused by an earlier commit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7367) Specify memory usage for Cargo test containers
[ https://issues.apache.org/jira/browse/GEODE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross resolved GEODE-7367. Resolution: Fixed > Specify memory usage for Cargo test containers > -- > > Key: GEODE-7367 > URL: https://issues.apache.org/jira/browse/GEODE-7367 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently the server container class used by cargo tests has no specification > for max and initial heap causing them to default to amounts much larger than > what our tests need. This has caused the Tomcat Cargo tests to use > significantly more memory than they need to and put additional stress on the > CI process. > We can fix this by specifying an appropriate amount of memory in the server > container's configuration object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7368) EntryNotFoundExceptions are thrown when sessions are evicted during unload
Benjamin P Ross created GEODE-7368: -- Summary: EntryNotFoundExceptions are thrown when sessions are evicted during unload Key: GEODE-7368 URL: https://issues.apache.org/jira/browse/GEODE-7368 Project: Geode Issue Type: Bug Components: http session Reporter: Benjamin P Ross During the unload process (DeltaSessionManager) we write our current sessions to disk and delete them from our session region. It's possible for a session to be evicted while this process is ongoing which results in an EntryNotFound exception which interrupts the process of clearing out the region. We can fix this by catching the exception and ignoring it - there is no circumstance where we want to change behavior if an entry is evicted right as we go to delete it in this process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7367) Specify memory usage for Cargo test containers
[ https://issues.apache.org/jira/browse/GEODE-7367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7367: --- Summary: Specify memory usage for Cargo test containers (was: Specify memory usage for Cargo) > Specify memory usage for Cargo test containers > -- > > Key: GEODE-7367 > URL: https://issues.apache.org/jira/browse/GEODE-7367 > Project: Geode > Issue Type: Improvement > Components: tests >Reporter: Benjamin P Ross >Priority: Major > > Currently the server container class used by cargo tests has no specification > for max and initial heap causing them to default to amounts much larger than > what our tests need. This has caused the Tomcat Cargo tests to use > significantly more memory than they need to and put additional stress on the > CI process. > We can fix this by specifying an appropriate amount of memory in the server > container's configuration object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7367) Specify memory usage for Cargo
Benjamin P Ross created GEODE-7367: -- Summary: Specify memory usage for Cargo Key: GEODE-7367 URL: https://issues.apache.org/jira/browse/GEODE-7367 Project: Geode Issue Type: Improvement Components: tests Reporter: Benjamin P Ross Currently the server container class used by cargo tests has no specification for max and initial heap causing them to default to amounts much larger than what our tests need. This has caused the Tomcat Cargo tests to use significantly more memory than they need to and put additional stress on the CI process. We can fix this by specifying an appropriate amount of memory in the server container's configuration object. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6326) testConcurrentEventsOnEmptyRegion fails in CI in multiple configurations
[
https://issues.apache.org/jira/browse/GEODE-6326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16961242#comment-16961242
]
Benjamin P Ross commented on GEODE-6326:
Failed in CI:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark/builds/639
> testConcurrentEventsOnEmptyRegion fails in CI in multiple configurations
>
>
> Key: GEODE-6326
> URL: https://issues.apache.org/jira/browse/GEODE-6326
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Dale Emery
>Priority: Major
> Labels: flaky
>
> DistributedAckOverflowRegionCCEDUnitTest.versionTestConcurrentEventsOnEmptyRegion
> failed in CI:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/335]
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0375/test-results/distributedTest/1548465595/classes/org.apache.geode.cache30.DistributedAckOverflowRegionCCEDUnitTest.html#testConcurrentEventsOnEmptyRegion]:
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Condition with alias 'Wait for
> the members to eventually be consistent' didn't complete within 300 seconds
> because assertion condition defined as a lambda expression in
> org.apache.geode.cache30.MultiVMRegionTestCase that uses
> org.apache.geode.test.dunit.VM,
> org.apache.geode.test.dunit.VMorg.apache.geode.test.dunit.VM,
> org.apache.geode.test.dunit.VMorg.apache.geode.test.dunit.VM [r2 contents are
> not consistent with r1 for cckey2] expected:<"ccvalue[-100586808]"> but
> was:<"ccvalue[1574152144]">.
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.cache30.MultiVMRegionTestCase.versionTestConcurrentEventsOnEmptyRegion(MultiVMRegionTestCase.java:8282)
> at
> org.apache.geode.cache30.DistributedAckRegionCCEDUnitTest.testConcurrentEventsOnEmptyRegion(DistributedAckRegionCCEDUnitTest.java:421)
> 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:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 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.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:66)
[jira] [Created] (GEODE-7204) Add documentation for Asynchronous Event Queue pause-event-processing configuration
Benjamin P Ross created GEODE-7204: -- Summary: Add documentation for Asynchronous Event Queue pause-event-processing configuration Key: GEODE-7204 URL: https://issues.apache.org/jira/browse/GEODE-7204 Project: Geode Issue Type: Improvement Components: docs, gfsh Reporter: Benjamin P Ross With the work done for https://issues.apache.org/jira/browse/GEODE-7121 we've added the new configuration attribute to Async Event Queues. We should add references to this in our documentation for cache-xml, the AsyncEventQueueFactory class, and the create/alter async-event-queue commands. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914645#comment-16914645
]
Benjamin P Ross commented on GEODE-7122:
This issue is very similar to
https://issues.apache.org/jira/browse/GEODE-6953?jql=text%20~%20%22RedundancyLevelPart1DUnitTest%22
and may have a similar cause.
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> RedundancyLevelPart1DUnitTest.
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
> DistributedTestOpenJDK8 build 1023:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1023
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-7122:
---
Description:
RedundancyLevelPart1DUnitTest.
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
DistributedTestOpenJDK8 build 1023:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1023
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
was:
RedundancyLevelPart1DUnitTest.
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
DistributedTestOpenJDK8 build 1023:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> RedundancyLevelPart1DUnitTest.
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
> DistributedTestOpenJDK8 build 1023:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1023
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-7122:
---
Description:
RedundancyLevelPart1DUnitTest.
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
DistributedTestOpenJDK8 build 1023:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
was:
RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
failed in DistributedTestOpenJDK11 build 762:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> RedundancyLevelPart1DUnitTest.
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
> DistributedTestOpenJDK8 build 1023:
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-7122:
---
Description:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
was:
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin P Ross updated GEODE-7122:
---
Description:
RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
failed in DistributedTestOpenJDK11 build 762:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
was:
{noformat}
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
{noformat}
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByPut
> failed in DistributedTestOpenJDK11 build 762:
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
Benjamin P Ross created GEODE-7122: -- Summary: CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure Key: GEODE-7122 URL: https://issues.apache.org/jira/browse/GEODE-7122 Project: Geode Issue Type: Improvement Reporter: Benjamin P Ross org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[ https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7122: --- Issue Type: Bug (was: Improvement) > CI failure: RedundancyLevelPart1DUnitTest > testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed > with ComparisonFailure > --- > > Key: GEODE-7122 > URL: https://issues.apache.org/jira/browse/GEODE-7122 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Priority: Major > > org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest > > testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256) -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16914636#comment-16914636
]
Benjamin P Ross commented on GEODE-6645:
We saw another occurrence of this issue in a CI failure:
https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK8/builds/910.
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Kirk Lund
>Priority: Major
> Labels: CI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>
[jira] [Updated] (GEODE-7110) Improve Integration test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7110: --- Labels: GeodeCommons (was: ) > Improve Integration test coverage for Tomcat session state module > - > > Key: GEODE-7110 > URL: https://issues.apache.org/jira/browse/GEODE-7110 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our Integration test coverage is significantly lacking for the Tomcat session > state module. This story aims to improve test coverage of that module. > Write Integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Currently the only integration tests the module has are util tests and > Tomcat6Session testing. Since tomcat 6 is deprecated and we have support as > far as Tomcat 9 in the product we should add similar tests for Tomcat 7-9. > Additionally, this testing seems to be peer to peer so we should consider > creating a client-server version as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7109: --- Labels: GeodeCommons (was: ) > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7109: --- Component/s: tests http session > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7110) Improve Integration test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7110: --- Component/s: tests http session > Improve Integration test coverage for Tomcat session state module > - > > Key: GEODE-7110 > URL: https://issues.apache.org/jira/browse/GEODE-7110 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our Integration test coverage is significantly lacking for the Tomcat session > state module. This story aims to improve test coverage of that module. > Write Integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Currently the only integration tests the module has are util tests and > Tomcat6Session testing. Since tomcat 6 is deprecated and we have support as > far as Tomcat 9 in the product we should add similar tests for Tomcat 7-9. > Additionally, this testing seems to be peer to peer so we should consider > creating a client-server version as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6874) Improve Unit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6874: --- Summary: Improve Unit test coverage for Tomcat session state module (was: Improve test coverage for Tomcat session state module) > Improve Unit test coverage for Tomcat session state module > -- > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-6874) Improve test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912695#comment-16912695 ] Benjamin P Ross commented on GEODE-6874: This issue is related to https://issues.apache.org/jira/browse/GEODE-7109 and https://issues.apache.org/jira/browse/GEODE-7110. > Improve test coverage for Tomcat session state module > - > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7110) Improve Integration test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912691#comment-16912691 ] Benjamin P Ross commented on GEODE-7110: This story is related to https://issues.apache.org/jira/browse/GEODE-7109 and https://issues.apache.org/jira/browse/GEODE-6874. > Improve Integration test coverage for Tomcat session state module > - > > Key: GEODE-7110 > URL: https://issues.apache.org/jira/browse/GEODE-7110 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our Integration test coverage is significantly lacking for the Tomcat session > state module. This story aims to improve test coverage of that module. > Write Integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Currently the only integration tests the module has are util tests and > Tomcat6Session testing. Since tomcat 6 is deprecated and we have support as > far as Tomcat 9 in the product we should add similar tests for Tomcat 7-9. > Additionally, this testing seems to be peer to peer so we should consider > creating a client-server version as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Commented] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16912692#comment-16912692 ] Benjamin P Ross commented on GEODE-7109: This issue is related to https://issues.apache.org/jira/browse/GEODE-7110 and https://issues.apache.org/jira/browse/GEODE-6874. > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7110) Improve Integration test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7110: --- Description: Our Integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module. Write Integration tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction Currently the only integration tests the module has are util tests and Tomcat6Session testing. Since tomcat 6 is deprecated and we have support as far as Tomcat 9 in the product we should add similar tests for Tomcat 7-9. Additionally, this testing seems to be peer to peer so we should consider creating a client-server version as well. was: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction > Improve Integration test coverage for Tomcat session state module > - > > Key: GEODE-7110 > URL: https://issues.apache.org/jira/browse/GEODE-7110 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our Integration test coverage is significantly lacking for the Tomcat session > state module. This story aims to improve test coverage of that module. > Write Integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Currently the only integration tests the module has are util tests and > Tomcat6Session testing. Since tomcat 6 is deprecated and we have support as > far as Tomcat 9 in the product we should add similar tests for Tomcat 7-9. > Additionally, this testing seems to be peer to peer so we should consider > creating a client-server version as well. -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7110) Improve Integration test coverage for Tomcat session state module
Benjamin P Ross created GEODE-7110: -- Summary: Improve Integration test coverage for Tomcat session state module Key: GEODE-7110 URL: https://issues.apache.org/jira/browse/GEODE-7110 Project: Geode Issue Type: Improvement Reporter: Benjamin P Ross * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7109: --- Description: Our DUnit test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module. Write DUnit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). was: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our DUnit test coverage is significantly lacking for the Tomcat session state > module. This story aims to improve test coverage of that module. > Write DUnit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7109: --- Description: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). was: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: DeltaSessionAttributeEventBatch DeltaSessionDestroyAttributeEvent DeltaSessionStatistics DeltaSessionUpdateAttributeEvent AbstractSessionCache ClientServerSessionCache CommitSessionValve DeltaSession DeltaSessionFacade DeltaSessionManager JvmRouteBinderValve PeerToPeerSessionCache SessionExpirationCacheListener Options Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6874) Improve test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6874: --- Description: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener * TouchReplicatedRegionEntriesFunction * TouchPartitionedRegionEntriesFunction was: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener > Improve test coverage for Tomcat session state module > - > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > * TouchReplicatedRegionEntriesFunction > * TouchPartitionedRegionEntriesFunction -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-7109: --- Description: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: DeltaSessionAttributeEventBatch DeltaSessionDestroyAttributeEvent DeltaSessionStatistics DeltaSessionUpdateAttributeEvent AbstractSessionCache ClientServerSessionCache CommitSessionValve DeltaSession DeltaSessionFacade DeltaSessionManager JvmRouteBinderValve PeerToPeerSessionCache SessionExpirationCacheListener Options Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). was:Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). > Improve DUnit test coverage for Tomcat session state module > --- > > Key: GEODE-7109 > URL: https://issues.apache.org/jira/browse/GEODE-7109 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Priority: Major > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > DeltaSessionAttributeEventBatch > DeltaSessionDestroyAttributeEvent > DeltaSessionStatistics > DeltaSessionUpdateAttributeEvent > AbstractSessionCache > ClientServerSessionCache > CommitSessionValve > DeltaSession > DeltaSessionFacade > DeltaSessionManager > JvmRouteBinderValve > PeerToPeerSessionCache > SessionExpirationCacheListener > Options > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6874) Improve test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6874: --- Description: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener was: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit and/or integration tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener > Improve test coverage for Tomcat session state module > - > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7109) Improve DUnit test coverage for Tomcat session state module
Benjamin P Ross created GEODE-7109: -- Summary: Improve DUnit test coverage for Tomcat session state module Key: GEODE-7109 URL: https://issues.apache.org/jira/browse/GEODE-7109 Project: Geode Issue Type: Improvement Reporter: Benjamin P Ross Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Updated] (GEODE-6874) Improve test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6874: --- Description: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit tests. Write unit and/or integration tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener was: Our unit and integration test coverage is significantly lacking for the Tomcat session state module. This story aims to improve test coverage of that module via unit, integration and DUnit tests. Write unit and/or integration tests for the following classes: * DeltaSessionAttributeEventBatch * DeltaSessionDestroyAttributeEvent * DeltaSessionStatistics * DeltaSessionUpdateAttributeEvent * AbstractSessionCache * ClientServerSessionCache * CommitSessionValve * DeltaSession * DeltaSessionFacade * DeltaSessionManager * JvmRouteBinderValve * PeerToPeerSessionCache * SessionExpirationCacheListener Write DUnit tests to exercise all versions of Tomcat with client-server and peer-to-peer topologies, with and without local caching enabled. We also want to exercise rebalance, resource management (thresholds), and commit behavior (CommitSessionValve) related configuration as described in the docs. We should scale these tests and the system level tests to do a more realistic workload. A lot of them add a single entry to the session store with just one or two containers. ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). > Improve test coverage for Tomcat session state module > - > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit tests. > Write unit and/or integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Assigned] (GEODE-6874) Improve test coverage for Tomcat session state module
[ https://issues.apache.org/jira/browse/GEODE-6874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-6874: -- Assignee: Benjamin P Ross > Improve test coverage for Tomcat session state module > - > > Key: GEODE-6874 > URL: https://issues.apache.org/jira/browse/GEODE-6874 > Project: Geode > Issue Type: Improvement > Components: http session, tests >Reporter: Ryan McMahon >Assignee: Benjamin P Ross >Priority: Major > Labels: GeodeCommons > > Our unit and integration test coverage is significantly lacking for the > Tomcat session state module. This story aims to improve test coverage of > that module via unit, integration and DUnit tests. > Write unit and/or integration tests for the following classes: > * DeltaSessionAttributeEventBatch > * DeltaSessionDestroyAttributeEvent > * DeltaSessionStatistics > * DeltaSessionUpdateAttributeEvent > * AbstractSessionCache > * ClientServerSessionCache > * CommitSessionValve > * DeltaSession > * DeltaSessionFacade > * DeltaSessionManager > * JvmRouteBinderValve > * PeerToPeerSessionCache > * SessionExpirationCacheListener > Write DUnit tests to exercise all versions of Tomcat with client-server and > peer-to-peer topologies, with and without local caching enabled. We also > want to exercise rebalance, resource management (thresholds), and commit > behavior (CommitSessionValve) related configuration as described in the docs. > We should scale these tests and the system level tests to do a more > realistic workload. A lot of them add a single entry to the session store > with just one or two containers. > ([https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_changing_gf_default_cfg.html]). -- This message was sent by Atlassian Jira (v8.3.2#803003)
[jira] [Created] (GEODE-7098) Tomcat8SessionsClientServerDUnitTest fails with ConnectException
Benjamin P Ross created GEODE-7098: -- Summary: Tomcat8SessionsClientServerDUnitTest fails with ConnectException Key: GEODE-7098 URL: https://issues.apache.org/jira/browse/GEODE-7098 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross We've seen Tomcat8SessionsClientServerDUnitTest.testExtraSessionsNotCreated fail with a ConnectException org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > testExtraSessionsNotCreated FAILED java.net.ConnectException: Connection refused (Connection refused) Caused by: java.net.ConnectException: Connection refused (Connection refused) This could be an environmental error, but if a pattern develops it could be due to a flaky test. -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Updated] (GEODE-6978) putIfAbsent returns improper value after vm restart
[ https://issues.apache.org/jira/browse/GEODE-6978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6978: --- Description: (was: Host name: rs-FullRegression17040158a2i32xlarge-hydra-client-11 OS name: Linux Architecture: amd64 OS version: 3.10.0-957.21.3.el7.x86_64 Java version: 1.8.0_211 Java vm name: Java HotSpot(TM) 64-Bit Server VM Java vendor: Oracle Corporation Java home: /usr/local/regr/jdk/jdk1.8.0_211/jre # Product Product-Name: Pivotal GemFire Product-Version: 9.9.0-build.0236 Build Build-Date: 2019-07-17 01:27:49 + Build-Id: geode Build-Java-Version: 1.8.0_212 Build-Platform: Linux 4.15.0-1036-gcp amd64 Open Source-Date: 2019-07-16 20:58:43 + Source-Repository: develop Source-Revision: 412570cb81321b526f44628eb7ed135bec11046e Running on: /10.32.109.231, 8 cpu(s), amd64 Linux 3.10.0-957.21.3.el7.x86_64 # Test was run from pdx/parRegPdxSerializer.bt Test: pdx/parReg/concParRegHAPersistPdx.conf A=accessor B=dataStore accessorHosts=1 accessorThreadsPerVM=5 accessorVMsPerHost=1 dataStoreHosts=6 dataStoreThreadsPerVM=5 dataStoreVMsPerHost=1 locatorHosts=1 locatorThreadsPerVM=1 locatorVMsPerHost=1 numVMsToStop=5 redundantCopies=3 Run with local.conf: util.ValueHolderPrms-objectType = util.VersionedValueHolder; // for parReg pdx tests diskRecovery.RecoveryPrms-valueClassName = util.VersionedValueHolder;// for diskRecovery tests cq.CQUtilPrms-objectType = util.VersionedQueryObject;// for cq pdx tests newWan.CacheClientPrms-objectType = util.VersionedValueHolder; // for wan pdx tests hydra.CachePrms-pdxSerializerInstantiator = pdx.PdxTestVersionHelper instantiatePdxSerializer; pdx.PdxPrms-pdxSerializerClassName = util.PdxTestSerializer; hydra.Prms-useFixedRandomInMaster= true; // lock down value of pdxReadSerialized hydra.CachePrms-pdxReadSerialized = ONEOF true false FOENO; //randomSeed extracted from test: hydra.Prms-randomSeed=1563345995612; *** Test failed with this error: CLIENT vm_0_thr_1_accessor1_host1_11355 TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps ERROR util.TestException: Expected return value from putIfAbsent to be null but it is util.TestException: Expected return value from putIfAbsent to be null but it is at parReg.ParRegTest.putIfAbsentAsCreate(ParRegTest.java:4229) at parReg.ParRegTest.doEntryOperations(ParRegTest.java:2811) at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2139) at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1039) at sun.reflect.GeneratedMethodAccessor217.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at hydra.MethExecutor.execute(MethExecutor.java:173) at hydra.MethExecutor.execute(MethExecutor.java:141) at hydra.TestTask.execute(TestTask.java:197) at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213)) > putIfAbsent returns improper value after vm restart > --- > > Key: GEODE-6978 > URL: https://issues.apache.org/jira/browse/GEODE-6978 > Project: Geode > Issue Type: Bug >Reporter: Benjamin P Ross >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Created] (GEODE-6978) putIfAbsent returns improper value after vm restart
Benjamin P Ross created GEODE-6978: -- Summary: putIfAbsent returns improper value after vm restart Key: GEODE-6978 URL: https://issues.apache.org/jira/browse/GEODE-6978 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross Host name: rs-FullRegression17040158a2i32xlarge-hydra-client-11 OS name: Linux Architecture: amd64 OS version: 3.10.0-957.21.3.el7.x86_64 Java version: 1.8.0_211 Java vm name: Java HotSpot(TM) 64-Bit Server VM Java vendor: Oracle Corporation Java home: /usr/local/regr/jdk/jdk1.8.0_211/jre # Product Product-Name: Pivotal GemFire Product-Version: 9.9.0-build.0236 Build Build-Date: 2019-07-17 01:27:49 + Build-Id: geode Build-Java-Version: 1.8.0_212 Build-Platform: Linux 4.15.0-1036-gcp amd64 Open Source-Date: 2019-07-16 20:58:43 + Source-Repository: develop Source-Revision: 412570cb81321b526f44628eb7ed135bec11046e Running on: /10.32.109.231, 8 cpu(s), amd64 Linux 3.10.0-957.21.3.el7.x86_64 # Test was run from pdx/parRegPdxSerializer.bt Test: pdx/parReg/concParRegHAPersistPdx.conf A=accessor B=dataStore accessorHosts=1 accessorThreadsPerVM=5 accessorVMsPerHost=1 dataStoreHosts=6 dataStoreThreadsPerVM=5 dataStoreVMsPerHost=1 locatorHosts=1 locatorThreadsPerVM=1 locatorVMsPerHost=1 numVMsToStop=5 redundantCopies=3 Run with local.conf: util.ValueHolderPrms-objectType = util.VersionedValueHolder; // for parReg pdx tests diskRecovery.RecoveryPrms-valueClassName = util.VersionedValueHolder;// for diskRecovery tests cq.CQUtilPrms-objectType = util.VersionedQueryObject;// for cq pdx tests newWan.CacheClientPrms-objectType = util.VersionedValueHolder; // for wan pdx tests hydra.CachePrms-pdxSerializerInstantiator = pdx.PdxTestVersionHelper instantiatePdxSerializer; pdx.PdxPrms-pdxSerializerClassName = util.PdxTestSerializer; hydra.Prms-useFixedRandomInMaster= true; // lock down value of pdxReadSerialized hydra.CachePrms-pdxReadSerialized = ONEOF true false FOENO; //randomSeed extracted from test: hydra.Prms-randomSeed=1563345995612; *** Test failed with this error: CLIENT vm_0_thr_1_accessor1_host1_11355 TASK[1] parReg.ParRegTest.HydraTask_HADoEntryOps ERROR util.TestException: Expected return value from putIfAbsent to be null but it is util.TestException: Expected return value from putIfAbsent to be null but it is at parReg.ParRegTest.putIfAbsentAsCreate(ParRegTest.java:4229) at parReg.ParRegTest.doEntryOperations(ParRegTest.java:2811) at parReg.ParRegTest.HADoEntryOps(ParRegTest.java:2139) at parReg.ParRegTest.HydraTask_HADoEntryOps(ParRegTest.java:1039) at sun.reflect.GeneratedMethodAccessor217.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at hydra.MethExecutor.execute(MethExecutor.java:173) at hydra.MethExecutor.execute(MethExecutor.java:141) at hydra.TestTask.execute(TestTask.java:197) at hydra.RemoteTestModule$1.run(RemoteTestModule.java:213) -- This message was sent by Atlassian JIRA (v7.6.14#76016)
[jira] [Commented] (GEODE-6867) Fix documentation for session state caching
[
https://issues.apache.org/jira/browse/GEODE-6867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16882369#comment-16882369
]
Benjamin P Ross commented on GEODE-6867:
We identified that there are several issues in the docs when setting up the
[client/server
topology|https://geode.apache.org/docs/guide/19/tools_modules/http_session_mgmt/tomcat_setting_up_the_module.html]
with Tomcat as well.
This entire section of the document could be included as a script along with
our module jars, instead of requiring the user to do manual steps.
If we just update the manual steps, here are some issues we found:
1. The list of jars to include in the CLASSPATH is incomplete. It either needs
to be updated to include the missing jars, or perhaps a wildcard on the libs
directory would work. It seems like the TC_VER and INSTANCE variables aren't
necessary, and instead $CATALINA_HOME/lib can be used.
2. Tomcat 6.0 is deprecated and the module is no longer included in our
packages, so we should remove the section in the docs on that version.
3. Copy pasting doesn't work for config changes because of extra whitespace in
the doc
> Fix documentation for session state caching
> ---
>
> Key: GEODE-6867
> URL: https://issues.apache.org/jira/browse/GEODE-6867
> Project: Geode
> Issue Type: Bug
> Components: docs, http session
>Reporter: Ryan McMahon
>Priority: Major
> Labels: GeodeCommons
>
> This story outlines two major issues in the session state docs, but I think
> the docs deserve a fairly comprehensive review to determine if there is any
> other stale/incorrect information. The two issues are:
> # Required jar list is missing some required jars
> # Need to indicate that a locator MUST be available for peer-to-peer topology
> More details on both issues below:
> We should review the session state documentation for
> completeness/correctness. When attempting to install and configure the
> Tomcat and AppServer session modules by following the docs, I found that
> there were missing jars in the [installation
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html]]
> for Tomcat and [setting up
> section|[https://gemfire.docs.pivotal.io/98/geode/tools_modules/http_session_mgmt/weblogic_setting_up_the_module.html]].
> Namely, I had to add these missing jars (as of 9.8, maybe earlier).
> * micrometer-core jar
> * geode-commons jar
> * geode-management jar
> The first is a new jar added since this documentation was written, and I'm
> assuming the code was restructured to require the other two jars as
> dependencies. I'm not sure how we can ensure that this list is up to date.
> Some of our system level tests for session state have to include the same
> list. From TomcatInstall.java:
> {code:java}
> private static final String[] tomcatRequiredJars =
> {"antlr", "commons-io", "commons-lang", "commons-validator", "fastutil",
> "geode-common",
> "geode-core", "geode-management", "javax.transaction-api", "jgroups",
> "log4j-api",
> "log4j-core", "log4j-jul", "micrometer", "shiro-core", "jetty-server",
> "jetty-util",
> "jetty-http", "jetty-io"};{code}
> And you can see that this list was updated to make the tests pass when
> dependencies changed.
> The other major issue I found while running through the steps is that you
> MUST start a locator in the peer-to-peer topology for session state, because
> multicast UDP discovery is not available/supported in Geode.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6937) LuceneIndexDestroyDUnitTest.verifyCreateDestroyDefinedIndex fails with OutOfMemoryError
Benjamin P Ross created GEODE-6937: -- Summary: LuceneIndexDestroyDUnitTest.verifyCreateDestroyDefinedIndex fails with OutOfMemoryError Key: GEODE-6937 URL: https://issues.apache.org/jira/browse/GEODE-6937 Project: Geode Issue Type: Bug Reporter: Benjamin P Ross We saw a failure for this test in a CI run with the following stack trace repeatedly found in the logs: java.lang.OutOfMemoryError: Java heap space at java.base/java.nio.HeapByteBuffer.(HeapByteBuffer.java:61) at java.base/java.nio.ByteBuffer.allocate(ByteBuffer.java:348) at org.apache.geode.cache.lucene.internal.filesystem.FileOutputStream.(FileOutputStream.java:33) at org.apache.geode.cache.lucene.internal.filesystem.File.getOutputStream(File.java:99) at org.apache.geode.cache.lucene.internal.directory.RegionDirectory.createOutput(RegionDirectory.java:79) at org.apache.lucene.store.LockValidatingDirectoryWrapper.createOutput(LockValidatingDirectoryWrapper.java:44) at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:43) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsWriter.(CompressingStoredFieldsWriter.java:117) at org.apache.lucene.codecs.compressing.CompressingStoredFieldsFormat.fieldsWriter(CompressingStoredFieldsFormat.java:128) at org.apache.lucene.codecs.lucene50.Lucene50StoredFieldsFormat.fieldsWriter(Lucene50StoredFieldsFormat.java:183) at org.apache.lucene.index.StoredFieldsConsumer.initStoredFieldsWriter(StoredFieldsConsumer.java:39) at org.apache.lucene.index.StoredFieldsConsumer.startDocument(StoredFieldsConsumer.java:46) at org.apache.lucene.index.DefaultIndexingChain.startStoredFields(DefaultIndexingChain.java:364) at org.apache.lucene.index.DefaultIndexingChain.processDocument(DefaultIndexingChain.java:398) at org.apache.lucene.index.DocumentsWriterPerThread.updateDocuments(DocumentsWriterPerThread.java:273) at org.apache.lucene.index.DocumentsWriter.updateDocuments(DocumentsWriter.java:433) at org.apache.lucene.index.IndexWriter.updateDocuments(IndexWriter.java:1384) at org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImpl.update(IndexRepositoryImpl.java:125) at org.apache.geode.cache.lucene.internal.LuceneEventListener.process(LuceneEventListener.java:97) at org.apache.geode.cache.lucene.internal.LuceneEventListener.processEvents(LuceneEventListener.java:69) at org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:150) at org.apache.geode.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:78) at org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:643) at org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1109) The CI run can be found here: https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/866 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6426) CI failure: org.apache.geode.internal.cache.PersistentPartitionedRegionJUnitTest.testValuesAreNotRecoveredForEntryLruRegionWithRegionClose failed with NPE
[ https://issues.apache.org/jira/browse/GEODE-6426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16879407#comment-16879407 ] Benjamin P Ross commented on GEODE-6426: Saw this in a CI run: https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/106 > CI failure: > org.apache.geode.internal.cache.PersistentPartitionedRegionJUnitTest.testValuesAreNotRecoveredForEntryLruRegionWithRegionClose > failed with NPE > -- > > Key: GEODE-6426 > URL: https://issues.apache.org/jira/browse/GEODE-6426 > Project: Geode > Issue Type: Bug >Reporter: Lynn Gallinat >Assignee: Anilkumar Gingade >Priority: Major > > org.apache.geode.internal.cache.PersistentPartitionedRegionJUnitTest > > testValuesAreNotRecoveredForEntryLruRegionWithRegionClose FAILED > java.lang.NullPointerException > at > org.apache.geode.internal.cache.PersistentPartitionedRegionJUnitTest.createLRURegionAndValidateRecovery(PersistentPartitionedRegionJUnitTest.java:304) > at > org.apache.geode.internal.cache.PersistentPartitionedRegionJUnitTest.testValuesAreNotRecoveredForEntryLruRegionWithRegionClose(PersistentPartitionedRegionJUnitTest.java:263) > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0451/test-results/integrationTest/1550283608/ > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0451/test-artifacts/1550283608/windows-integrationtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0451.tgz -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6770) Allow Destroy Data Source command to deregister driver for JDBC connector with optional argument
[ https://issues.apache.org/jira/browse/GEODE-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6770: --- Component/s: docs > Allow Destroy Data Source command to deregister driver for JDBC connector > with optional argument > > > Key: GEODE-6770 > URL: https://issues.apache.org/jira/browse/GEODE-6770 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > When a data source for the JDBC connector is deleted, users may want to > deregister the driver being used by that data source. We can add an option to > do this to the destroy data-source command which will deregister any driver > associated with the given data source. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6773) Add gfsh commands for Register Driver, Deregister Driver, and List Driver to JDBC connector
Benjamin P Ross created GEODE-6773: -- Summary: Add gfsh commands for Register Driver, Deregister Driver, and List Driver to JDBC connector Key: GEODE-6773 URL: https://issues.apache.org/jira/browse/GEODE-6773 Project: Geode Issue Type: Improvement Components: docs Reporter: Benjamin P Ross While the JDBC connector has functionality to automatically register/deregister drivers with the creation of it's data source objects it would be convenient for users to register and deregister these manually as well. In order to facilitate this they will also need to be able to list the currently registered drivers. We should add the following gfsh commands to allow for this: Register Driver - A command which takes a name of a jar file which has been previously deployed into the geode cluster via the deploy command or the name of the JDBC driver class within it and registers the JDBC driver with the Driver Manager. Deregister Driver - A command which takes a name of a jar file which has been previously deployed into the geode cluster via the deploy command or the name of the JDBC driver class within it and deregisters the JDBC driver with the Driver Manager. List Drivers - A command which lists all driver classes that are currently registered with the driver manager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6770) Allow Destroy Data Source command to deregister driver for JDBC connector with optional argument
[ https://issues.apache.org/jira/browse/GEODE-6770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross reassigned GEODE-6770: -- Assignee: Benjamin P Ross > Allow Destroy Data Source command to deregister driver for JDBC connector > with optional argument > > > Key: GEODE-6770 > URL: https://issues.apache.org/jira/browse/GEODE-6770 > Project: Geode > Issue Type: Improvement >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > > When a data source for the JDBC connector is deleted, users may want to > deregister the driver being used by that data source. We can add an option to > do this to the destroy data-source command which will deregister any driver > associated with the given data source. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6669) Allow create data source command to specify driver jar for jdbc connector
[ https://issues.apache.org/jira/browse/GEODE-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin P Ross updated GEODE-6669: --- Component/s: docs > Allow create data source command to specify driver jar for jdbc connector > -- > > Key: GEODE-6669 > URL: https://issues.apache.org/jira/browse/GEODE-6669 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Benjamin P Ross >Assignee: Benjamin P Ross >Priority: Major > Time Spent: 1h 50m > Remaining Estimate: 0h > > In order to load a jdbc driver at runtime, we need to be able to deploy it to > the cluster. It would be most convenient for users if this could be done > automatically when they create their data source. We can do this by adding a > --driver-jar option to the create data source command which will load a > drivers from a path provided. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6770) Allow Destroy Data Source command to deregister driver for JDBC connector with optional argument
Benjamin P Ross created GEODE-6770: -- Summary: Allow Destroy Data Source command to deregister driver for JDBC connector with optional argument Key: GEODE-6770 URL: https://issues.apache.org/jira/browse/GEODE-6770 Project: Geode Issue Type: Improvement Reporter: Benjamin P Ross When a data source for the JDBC connector is deleted, users may want to deregister the driver being used by that data source. We can add an option to do this to the destroy data-source command which will deregister any driver associated with the given data source. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
