[jira] [Resolved] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availab
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10329.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at
[jira] [Commented] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availa
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17542224#comment-17542224
]
Donal Evans commented on GEODE-10329:
-
I was not able to reproduce this failure in 1000 repeat runs using both JDK 11
and JDK 17, but I believe that there is a possible race condition between
beginning shutdown of the GMSHealthMonitor (which stops the executor) and
submitting a task to the executor.
It should be simple to add a check for if the GMSHealthMonitor is shutting down
when encountering the exception and ignoring it if that's the case.
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at
[jira] [Assigned] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availab
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10329:
---
Assignee: Donal Evans
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> 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
[jira] [Updated] (GEODE-10330) Resource issues lead to "MemberDisconnectedException: Member isn't responding to heartbeat requests"
[
https://issues.apache.org/jira/browse/GEODE-10330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10330:
Description:
A failure was observed in
DistributedMulticastRegionWithUDPSecurityDUnitTest >
testMulticastAfterReconnect due to suspect strings with fatal-level logging of
"Membership service failure: Member isn't responding to heartbeat requests".
Investigating the logs showed all members reporting long statistics sampling
wakeup delays, indicating resource issues:
{code:java}
[vm3] [warn 2022/05/21 07:28:16.251 UTC LocatorWithMcast
tid=0xb8] Statistics sampling thread detected a wakeup delay of 4760 ms,
indicating a possible resource issue. Check the GC, memory, and CPU statistics.
...
[locator] [warn 2022/05/21 07:28:20.288 UTC tid=0x3b] Statistics
sampling thread detected a wakeup delay of 12400 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
...
[vm1] [warn 2022/05/21 07:28:20.969 UTC vm1 tid=0xda] Statistics
sampling thread detected a wakeup delay of 13738 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
...
[vm0] [warn 2022/05/21 07:28:22.226 UTC vm0 tid=0xa9] Statistics
sampling thread detected a wakeup delay of 15110 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics. {code}
After downloading the test artifacts and using the progress tool from the
dev-tools directory in the Geode repository, the following tests were found to
be running during the resource issues, possibly indicating that one or more of
them are particularly resource-intensive:
{noformat}
$> progress -r '2022-05-21 07:28:16.251 -' | grep org | sort{noformat}
{code:java}
org.apache.geode.cache.PRCacheListenerWithInterestPolicyAllDistributedTest.afterUpdateIsInvokedInEveryMember[0:
redundancy=0]
org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest.recreateIndexWithDifferentFieldsShouldFail(PARTITION_OVERFLOW_TO_DISK)
[2]
org.apache.geode.cache.query.cq.dunit.CqDataUsingPoolOptimizedExecuteDUnitTest.testCQHAWithState
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testPartitionedCqOnAccessorBridgeServer
org.apache.geode.cache30.CallbackArgDUnitTest.testForCA
org.apache.geode.cache30.DistributedMulticastRegionWithUDPSecurityDUnitTest.testMulticastAfterReconnect
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testDistributedInvalidate
org.apache.geode.cache30.GlobalRegionOffHeapDUnitTest.testOrderedUpdates
org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown
org.apache.geode.distributed.internal.P2PMessagingConcurrencyDUnitTest.testP2PMessaging(true,
false, 32768, 65536) [6]
org.apache.geode.disttx.PRDistTXDUnitTest.testSimulaneousChildRegionCreation
org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest.testClientCommitFunctionWithFailure
org.apache.geode.internal.cache.eviction.OffHeapEvictionStatsDUnitTest.testHeapLruCounter
org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOperation_1_DUnitTest.testParallelPropagationSenderStartAfterStopOnAccessorNode
org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDistributedTest.testParallelGatewaySenderStartOnAccessorNode
org.apache.geode.internal.cache.wan.serial.SerialWANPropagation_PartitionedRegionDUnitTest.testPartitionedSerialPropagationHA
org.apache.geode.internal.tcp.TCPConduitDUnitTest.basicAcceptConnection[0]
org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest.importFailWithExistingRegion
org.apache.geode.rest.internal.web.controllers.RestAPIsOnGroupsFunctionExecutionDUnitTest.testBasicP2PFunctionSelectedGroup[1]
org.apache.geode.session.tests.Jetty9CachingClientServerTest.failureShouldStillAllowOtherContainersDataAccess
org.apache.geode.session.tests.Tomcat8ClientServerCustomCacheXmlTest.containersShouldExpireInSetTimeframe
org.apache.geode.session.tests.Tomcat8Test.containersShouldReplicateCookies
org.apache.geode.session.tests.Tomcat9ClientServerTest.invalidationShouldRemoveValueAccessForAllContainers
{code}
Future failures due to this sort of resource issue should also list
concurrently running tests so that repeat appearances by individual tests can
be used to identify the culprits.
was:
A failure was observed in
DistributedMulticastRegionWithUDPSecurityDUnitTest >
testMulticastAfterReconnect due to suspect strings with fatal-level logging of
"Membership service failure: Member isn't responding to heartbeat requests".
Investigating the logs showed all members reporting long statistics sampling
wakeup delays, indicating resource issues:
{code:java}
[vm3] [warn 2022/05/21 07:28:16.251 UTC LocatorWithMcast
tid=0xb8] Statistics sampling thread detected a wakeup delay of 4760 ms,
indicating a possible resource
[jira] [Created] (GEODE-10330) Resource issues lead to "MemberDisconnectedException: Member isn't responding to heartbeat requests"
Donal Evans created GEODE-10330:
---
Summary: Resource issues lead to "MemberDisconnectedException:
Member isn't responding to heartbeat requests"
Key: GEODE-10330
URL: https://issues.apache.org/jira/browse/GEODE-10330
Project: Geode
Issue Type: Bug
Affects Versions: 1.16.0
Reporter: Donal Evans
A failure was observed in
DistributedMulticastRegionWithUDPSecurityDUnitTest >
testMulticastAfterReconnect due to suspect strings with fatal-level logging of
"Membership service failure: Member isn't responding to heartbeat requests".
Investigating the logs showed all members reporting long statistics sampling
wakeup delays, indicating resource issues:
{code:java}
[vm3] [warn 2022/05/21 07:28:16.251 UTC LocatorWithMcast
tid=0xb8] Statistics sampling thread detected a wakeup delay of 4760 ms,
indicating a possible resource issue. Check the GC, memory, and CPU statistics.
...
[locator] [warn 2022/05/21 07:28:20.288 UTC tid=0x3b] Statistics
sampling thread detected a wakeup delay of 12400 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
...
[vm1] [warn 2022/05/21 07:28:20.969 UTC vm1 tid=0xda] Statistics
sampling thread detected a wakeup delay of 13738 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics.
...
[vm0] [warn 2022/05/21 07:28:22.226 UTC vm0 tid=0xa9] Statistics
sampling thread detected a wakeup delay of 15110 ms, indicating a possible
resource issue. Check the GC, memory, and CPU statistics. {code}
Using the progress tool from the dev-tools directory in the Geode repository,
the following tests were found to be running during the resource issues,
possibly indicating that one or more of them are particularly
resource-intensive:
{noformat}
$> progress -r '2022-05-21 07:28:16.251 -' | grep org | sort{noformat}
{code:java}
org.apache.geode.cache.PRCacheListenerWithInterestPolicyAllDistributedTest.afterUpdateIsInvokedInEveryMember[0:
redundancy=0]
org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest.recreateIndexWithDifferentFieldsShouldFail(PARTITION_OVERFLOW_TO_DISK)
[2]
org.apache.geode.cache.query.cq.dunit.CqDataUsingPoolOptimizedExecuteDUnitTest.testCQHAWithState
org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testPartitionedCqOnAccessorBridgeServer
org.apache.geode.cache30.CallbackArgDUnitTest.testForCA
org.apache.geode.cache30.DistributedMulticastRegionWithUDPSecurityDUnitTest.testMulticastAfterReconnect
org.apache.geode.cache30.DistributedNoAckRegionCCEOffHeapDUnitTest.testDistributedInvalidate
org.apache.geode.cache30.GlobalRegionOffHeapDUnitTest.testOrderedUpdates
org.apache.geode.cache30.ReconnectWithClusterConfigurationDUnitTest.testReconnectAfterMeltdown
org.apache.geode.distributed.internal.P2PMessagingConcurrencyDUnitTest.testP2PMessaging(true,
false, 32768, 65536) [6]
org.apache.geode.disttx.PRDistTXDUnitTest.testSimulaneousChildRegionCreation
org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest.testClientCommitFunctionWithFailure
org.apache.geode.internal.cache.eviction.OffHeapEvictionStatsDUnitTest.testHeapLruCounter
org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOperation_1_DUnitTest.testParallelPropagationSenderStartAfterStopOnAccessorNode
org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDistributedTest.testParallelGatewaySenderStartOnAccessorNode
org.apache.geode.internal.cache.wan.serial.SerialWANPropagation_PartitionedRegionDUnitTest.testPartitionedSerialPropagationHA
org.apache.geode.internal.tcp.TCPConduitDUnitTest.basicAcceptConnection[0]
org.apache.geode.management.internal.configuration.ClusterConfigImportDUnitTest.importFailWithExistingRegion
org.apache.geode.rest.internal.web.controllers.RestAPIsOnGroupsFunctionExecutionDUnitTest.testBasicP2PFunctionSelectedGroup[1]
org.apache.geode.session.tests.Jetty9CachingClientServerTest.failureShouldStillAllowOtherContainersDataAccess
org.apache.geode.session.tests.Tomcat8ClientServerCustomCacheXmlTest.containersShouldExpireInSetTimeframe
org.apache.geode.session.tests.Tomcat8Test.containersShouldReplicateCookies
org.apache.geode.session.tests.Tomcat9ClientServerTest.invalidationShouldRemoveValueAccessForAllContainers
{code}
Future failures due to this sort of resource issue should also list
concurrently running tests so that repeat appearances by individual tests can
be used to identify the culprits.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10329:
Summary: CI Failure: PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to (was: CI
Failure: PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss)
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
>
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at
[jira] [Updated] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to RejectedExecutionException during member availabi
[
https://issues.apache.org/jira/browse/GEODE-10329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10329:
Summary: CI Failure: PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
RejectedExecutionException during member availability check (was: CI Failure:
PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to )
> CI Failure: PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss fails due to
> RejectedExecutionException during member availability check
> ---
>
> Key: GEODE-10329
> URL: https://issues.apache.org/jira/browse/GEODE-10329
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {code:java}
> > Task :geode-core:distributedTest
> PersistentPartitionedRegionDistributedTest >
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 662
> [fatal 2022/05/23 17:31:45.980 UTC
> tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
> 4,5,RMI Runtime]
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
> rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting
> down, pool size = 6, active threads = 5, queued tasks = 0, completed tasks =
> 7]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
> at
> org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
> at
> org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
> at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at
[jira] [Created] (GEODE-10329) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss
Donal Evans created GEODE-10329:
---
Summary: CI Failure: PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss
Key: GEODE-10329
URL: https://issues.apache.org/jira/browse/GEODE-10329
Project: Geode
Issue Type: Bug
Affects Versions: 1.16.0
Reporter: Donal Evans
{code:java}
> Task :geode-core:distributedTest
PersistentPartitionedRegionDistributedTest >
testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 662
[fatal 2022/05/23 17:31:45.980 UTC
tid=257] Uncaught exception in thread Thread[Geode Failure Detection thread
4,5,RMI Runtime]
java.util.concurrent.RejectedExecutionException: Task
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor$$Lambda$604/0x00080119f4f8@2f733640
rejected from java.util.concurrent.ThreadPoolExecutor@2aaf4890[Shutting down,
pool size = 6, active threads = 5, queued tasks = 0, completed tasks = 7]
at
java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)
at
java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)
at
java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:1241)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.processMessage(GMSHealthMonitor.java:1173)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.sendSuspectRequest(GMSHealthMonitor.java:1425)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.initiateSuspicion(GMSHealthMonitor.java:486)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.lambda$checkMember$1(GMSHealthMonitor.java:470)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
at org.junit.Assert.fail(Assert.java:89)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
at
org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
at
org.apache.geode.test.dunit.rules.DistributedRule$TearDown.doTearDown(DistributedRule.java:230)
at
org.apache.geode.test.dunit.rules.DistributedRule$TearDown.access$100(DistributedRule.java:211)
at
org.apache.geode.test.dunit.rules.DistributedRule.after(DistributedRule.java:151)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule.afterDistributedTest(AbstractDistributedRule.java:81)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:61)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
[jira] [Updated] (GEODE-9915) CI Failure: PersistentPartitionedRegionDistributedTest > testCacheCloseDuringBucketMoveDoesntCauseDataLoss
[
https://issues.apache.org/jira/browse/GEODE-9915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9915:
---
Description:
{code:java}
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest
> testCacheCloseDuringBucketMoveDoesntCauseDataLoss FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$317/1024935265.run
in VM 1 running on Host
heavy-lifter-61c6d5ff-ce00-5ec4-85ab-7bec8a9c5922.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
at
org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest.testCacheCloseDuringBucketMoveDoesntCauseDataLoss(PersistentPartitionedRegionDistributedTest.java:1364)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at
org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
at
org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:449)
at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at java.util.Iterator.forEachRemaining(Iterator.java:116)
at
java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:82)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:73)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
[jira] [Updated] (GEODE-974) CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-974:
--
Affects Version/s: 1.16.0
> CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup
> failed with AssertionError
> ---
>
> Key: GEODE-974
> URL: https://issues.apache.org/jira/browse/GEODE-974
> Project: Geode
> Issue Type: Bug
> Components: persistence
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Labels: CI, Flaky, pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Geode_develop_DistributedTests
> Private Build #1602 (Feb 13, 2016 9:09:53 AM)
> Revision: 781277f31f37388f7247cbdf05025c12de825d2a
> Error Message
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use DistributedTestCase.addExpectedException to ignore.
> ---
> Found suspect string in log4j at line 2919
> [fatal 2016/02/13 11:30:42.638 PST tid=0x580]
> Uncaught exception processing Alert "Error processing request class
> com.gemstone.gemfire.internal.admin.remote.PrepareRevokePersistentIDRequest."
> level ERROR
> java.lang.NullPointerException
> at
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getApplicationById(RemoteGfManagerAgent.java:606)
> at
> com.gemstone.gemfire.internal.admin.remote.RemoteGfManagerAgent.getMemberById(RemoteGfManagerAgent.java:592)
> at
> com.gemstone.gemfire.internal.admin.remote.AlertListenerMessage.process(AlertListenerMessage.java:83)
> at
> com.gemstone.gemfire.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:380)
> at
> com.gemstone.gemfire.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:451)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:656)
> at
> com.gemstone.gemfire.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:930)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Stacktrace
> {noformat}
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase$1.call
> in VM 0 running on Host cc4-rh6.gemstone.com with 4 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:372)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:315)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:281)
> at
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.createDefaultSetup(CliCommandTestBase.java:105)
> at
> com.gemstone.gemfire.management.internal.cli.commands.CreateAlterDestroyRegionCommandsDUnitTest.testCreateRegion46391(CreateAlterDestroyRegionCommandsDUnitTest.java:290)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at
>
[jira] [Updated] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10297:
Fix Version/s: 1.15.0
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, needsTriage, pull-request-available
> Fix For: 1.15.0, 1.16.0
>
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10297.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, needsTriage, pull-request-available
> Fix For: 1.16.0
>
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10297) SSL protocol ordering can result in loss of newer protocol support.
[
https://issues.apache.org/jira/browse/GEODE-10297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10297:
---
Assignee: Donal Evans
> SSL protocol ordering can result in loss of newer protocol support.
> ---
>
> Key: GEODE-10297
> URL: https://issues.apache.org/jira/browse/GEODE-10297
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.9, 1.13.8, 1.14.4, 1.15.0, 1.16.0
>Reporter: Jacob Barrett
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> If {{ssl-protocols}} is listed with a older protocol version ahead of a newer
> the {{SSLContext}} used will support at most that weaker protocol.
> For example {{ssl-protocols=TLSV1.2,TLSv1.3,TLSv1.1}} will use the
> {{TLSv1.2}} {{SSLContext}}, which will not support, and silently ignore, the
> {{TLSv1.3}} configuration. The effective enabled protocols list will be
> {{TLSV1.2,TLSv1.1}}.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Reopened] (GEODE-10196) Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reopened GEODE-10196:
-
Reopening because of the failure in HdelDUnitTest linked in the above run.
I did a quick search and it seems like that is the only other test that is
checking the full exception message, but there are also a few other places
where we look for "Connection reset by peer" rather than "Connection reset",
those being RedisProxyInboundHandler.java, RedisProxyOutboundHandler.java and
MessageDispatcher.java, so those might need attention too.
> Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK
> 17
>
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
>
[jira] [Updated] (GEODE-10196) Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10196:
Summary: Multiple geode-for-redis DUnitTests fail to ignore expected
exceptions on JDK 17 (was: HashesAndCrashesDUnitTest fails to ignore expected
exceptions on JDK 17)
> Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK
> 17
>
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
>
[jira] [Resolved] (GEODE-9914) CI Failures: JmxServerReconnectDistributedTest
[ https://issues.apache.org/jira/browse/GEODE-9914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9914. Resolution: Duplicate > CI Failures: JmxServerReconnectDistributedTest > -- > > Key: GEODE-9914 > URL: https://issues.apache.org/jira/browse/GEODE-9914 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.13.0, 1.14.0, 1.15.0 >Reporter: Ray Ingles >Priority: Major > > Multiple failures in the latest regression in different places. Possibly > related to bumping versions of dependencies due to Log4j bug fixes? -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8554) CI Failure: JMXMBeanReconnectDUnitTest.locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
[
https://issues.apache.org/jira/browse/GEODE-8554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-8554.
Resolution: Duplicate
> CI Failure:
> JMXMBeanReconnectDUnitTest.locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns
>
>
> Key: GEODE-8554
> URL: https://issues.apache.org/jira/browse/GEODE-8554
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Jianxia Chen
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.management.JMXMBeanReconnectDUnitTest >
> locatorMXBeansOnOtherLocatorAreRestoredAfterCrashedLocatorReturns FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.JMXMBeanReconnectDUnitTest$$Lambda$355/858468979.call
> in VM -1 running on Host 7a5c340f5c23 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:472)
> at
> org.apache.geode.management.JMXMBeanReconnectDUnitTest.setUp(JMXMBeanReconnectDUnitTest.java:191)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.JMXMBeanReconnectDUnitTest [GemFire mbeans on
> locator2]
> Expecting HashSet:
> <[GemFire:type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> GemFire:type=Member,member=server1,
> GemFire:service=Manager,type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator2,
> GemFire:type=Member,member=locator2,
> GemFire:service=Region,name=/region1,type=Member,member=server1,
> GemFire:service=FileUploader,type=Distributed,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator2,
> GemFire:service=Manager,type=Member,member=locator2,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=System,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=Region,name=/region1,type=Distributed]>
> to contain:
> <[GemFire:type=Member,member=locator1,
> GemFire:service=Locator,type=Member,member=locator1,
> GemFire:service=Manager,type=Member,member=locator1,
>
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> but could not find the following element(s):
>
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> 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.JMXMBeanReconnectDUnitTest.lambda$setUp$515fd116$3(JMXMBeanReconnectDUnitTest.java:192)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:617)
> ... 2 more
> Caused by:
> java.lang.AssertionError: [GemFire mbeans on locator2]
> Expecting HashSet:
> <[GemFire:type=Member,member=locator1,
>
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator2,
> GemFire:type=Member,member=server1,
> GemFire:service=Manager,type=Member,member=locator1,
>
[jira] [Resolved] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-7710.
Resolution: Duplicate
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> This test fails due to GEODE-7739. Enter new failures against that ticket.
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8709) ReplicatedFunctionExecutionBenchmark failing
[ https://issues.apache.org/jira/browse/GEODE-8709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531301#comment-17531301 ] Donal Evans commented on GEODE-8709: The above failure also shows a degradation in PartitionedPutAllLongBenchmark, which is tracked by GEODE-7572. It's worth noting that of the 5 repeats that we allow for benchmark instability to be minimized, 4 failed due to java.io.EOFException, which is a common occurrence in the benchmark runs, so we didn't get a chance to re-run the benchmarks showing the degradation to see if it was reproducible. Given the known instability in the benchmarks, these degradations seem like a stability issue rather than a real degradation. > ReplicatedFunctionExecutionBenchmark failing > - > > Key: GEODE-8709 > URL: https://issues.apache.org/jira/browse/GEODE-8709 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: John Hutchison >Priority: Major > Labels: benchmark > > > > org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionWithFiltersBenchmark > > average ops/second Baseline: 546625.03 Test: 537316.10 Difference: -1.7% > ops/second standard error Baseline: 776.77 Test: 709.95 Difference: -8.6% > s/second standard deviation Baseline: 13431.54 Test: 12276.10 Difference: > -8.6% > YS 99th percentile latency Baseline: 1700.00 Test: 1750.00 Difference: +2.9% > median latency Baseline: 1213439.00 Test: 1215487.00 Difference: +0.2% > 90th percentile latency Baseline: 1465343.00 Test: 1518591.00 Difference: > +3.6% > 99th percentile latency Baseline: 4517887.00 Test: 4636671.00 Difference: > +2.6% > 99.9th percentile latency Baseline: 18202623.00 Test: 19234815.00 > Difference: +5.7% > average latency Baseline: 1315053.32 Test: 1337898.07 Difference: +1.7% > latency standard deviation Baseline: 1303983.91 Test: 1335112.23 Difference: > +2.4% > latency standard error Baseline: 101.85 Test: 105.17 Difference: +3.3% > average ops/second Baseline: 546531.56 Test: 537283.96 Difference: -1.7% > BENCHMARK FAILED: > org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionBenchmark average > latency is 5% worse than baseline. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-8709) ReplicatedFunctionExecutionBenchmark failing
[ https://issues.apache.org/jira/browse/GEODE-8709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-8709: --- Affects Version/s: 1.15.0 > ReplicatedFunctionExecutionBenchmark failing > - > > Key: GEODE-8709 > URL: https://issues.apache.org/jira/browse/GEODE-8709 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: John Hutchison >Priority: Major > Labels: benchmark > > > > org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionWithFiltersBenchmark > > average ops/second Baseline: 546625.03 Test: 537316.10 Difference: -1.7% > ops/second standard error Baseline: 776.77 Test: 709.95 Difference: -8.6% > s/second standard deviation Baseline: 13431.54 Test: 12276.10 Difference: > -8.6% > YS 99th percentile latency Baseline: 1700.00 Test: 1750.00 Difference: +2.9% > median latency Baseline: 1213439.00 Test: 1215487.00 Difference: +0.2% > 90th percentile latency Baseline: 1465343.00 Test: 1518591.00 Difference: > +3.6% > 99th percentile latency Baseline: 4517887.00 Test: 4636671.00 Difference: > +2.6% > 99.9th percentile latency Baseline: 18202623.00 Test: 19234815.00 > Difference: +5.7% > average latency Baseline: 1315053.32 Test: 1337898.07 Difference: +1.7% > latency standard deviation Baseline: 1303983.91 Test: 1335112.23 Difference: > +2.4% > latency standard error Baseline: 101.85 Test: 105.17 Difference: +3.3% > average ops/second Baseline: 546531.56 Test: 537283.96 Difference: -1.7% > BENCHMARK FAILED: > org.apache.geode.benchmark.tests.ReplicatedFunctionExecutionBenchmark average > latency is 5% worse than baseline. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-7016) CI failure: ServerStartupRedundancyRecoveryNotificationTest > startupReportsOnlineOnlyAfterRedundancyRestored FAILED
[
https://issues.apache.org/jira/browse/GEODE-7016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7016:
---
Affects Version/s: 1.14.4
1.13.8
1.12.9
> CI failure: ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
>
>
> Key: GEODE-7016
> URL: https://issues.apache.org/jira/browse/GEODE-7016
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.10.0, 1.12.9, 1.13.8, 1.14.4
>Reporter: Anilkumar Gingade
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Attachments: acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (1).tgz,
> acceptancetestfiles-OpenJDK11-1.14.0-build.0628 (2).tgz
>
>
> {noformat}
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest >
> startupReportsOnlineOnlyAfterRedundancyRestored FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.startupReportsOnlineOnlyAfterRedundancyRestored(ServerStartupRedundancyRecoveryNotificationTest.java:142)
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:112)
> at
> org.apache.geode.launchers.ServerStartupRedundancyRecoveryNotificationTest.stopAllMembers(ServerStartupRedundancyRecoveryNotificationTest.java:128)
> {noformat}
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/AcceptanceTestOpenJDK8/builds/797
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.9.0-build.0258/test-artifacts/1564078711/acceptancetestfiles-OpenJDK8-9.9.0-build.0258.tgz
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-7960) CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion FAILED on Windows
[
https://issues.apache.org/jira/browse/GEODE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7960:
---
Affects Version/s: 1.14.4
1.13.8
1.12.10
> CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion
> FAILED on Windows
>
>
> Key: GEODE-7960
> URL: https://issues.apache.org/jira/browse/GEODE-7960
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.10, 1.13.8, 1.14.4
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>Priority: Major
>
> Looks like a flaky test on windows:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/21
> {noformat}
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest
> > logsMissingChildRegionUntilCompletion FAILED
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> But found this interaction on mock 'consumer':
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> 2. [?]-> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-7960) CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion FAILED on Windows
[
https://issues.apache.org/jira/browse/GEODE-7960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-7960:
---
Affects Version/s: 1.15.0
> CI: SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion
> FAILED on Windows
>
>
> Key: GEODE-7960
> URL: https://issues.apache.org/jira/browse/GEODE-7960
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.10, 1.13.8, 1.14.4, 1.15.0
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>Priority: Major
>
> Looks like a flaky test on windows:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/21
> {noformat}
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest
> > logsMissingChildRegionUntilCompletion FAILED
> org.mockito.exceptions.verification.NoInteractionsWanted:
> No interactions wanted here:
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> But found this interaction on mock 'consumer':
> -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> ***
> For your reference, here is the list of all invocations ([?] - means
> unverified).
> 1. -> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> 2. [?]-> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLogger.logMissingRegions(SingleThreadColocationLogger.java:229)
> at
> org.apache.geode.internal.cache.partitioned.colocation.SingleThreadColocationLoggerTest.logsMissingChildRegionUntilCompletion(SingleThreadColocationLoggerTest.java:180)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17529675#comment-17529675 ] Donal Evans commented on GEODE-10266: - [~mivanac] This failure is in a test that was recently [added in this PR|https://github.com/apache/geode/pull/7517] for GEODE-10020. It seems like the test is flaky. Would it be possible to assign this ticket to you since you wrote the test? It looks like there were two failures of the test in the PR pre-checkin while you were working on addressing review comments too, so ideally the PR would not have been merged until that had been addressed. First PR failure: [https://concourse.apachegeode-ci.info/builds/48410232#L626524d8:560] Second PR failure: [https://concourse.apachegeode-ci.info/builds/48456881#L6265370b:560] It's not clear yet what the failure rate for this test is, but if it's failing often, the commit may need to be reverted. > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10266: --- Assignee: (was: Donal Evans) > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10266) CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection Failed
[ https://issues.apache.org/jira/browse/GEODE-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10266: --- Assignee: Donal Evans > CI Failure: SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > Failed > --- > > Key: GEODE-10266 > URL: https://issues.apache.org/jira/browse/GEODE-10266 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Vince Ford >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > F : acceptance-test-openjdk8 > > Task :geode-assembly:acceptanceTest > SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > > testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection > FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > that uses org.apache.geode.test.dunit.VM, > org.apache.geode.test.dunit.VMjava.lang.String > expected: 4 > but was: 3 within 5 minutes. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testPingsToReceiversWithSamePortAndHostnameForSendersUseOnlyOneMoreConnection(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:261) > Caused by: > java.util.concurrent.TimeoutException > at java.util.concurrent.FutureTask.get(FutureTask.java:205) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:101) > at > org.awaitility.core.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:81) > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:103) > ... 5 more > 185 tests completed, 1 failed, 4 skipped > =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-results/acceptanceTest/1651109383/*] > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1127/test-artifacts/1651109383/acceptancetestfiles-openjdk8-1.15.0-build.1127.tgz*] -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10264) Geode user guide: remove the "Connect to the server from your application" section
[ https://issues.apache.org/jira/browse/GEODE-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10264: Labels: (was: needsTriage) > Geode user guide: remove the "Connect to the server from your application" > section > -- > > Key: GEODE-10264 > URL: https://issues.apache.org/jira/browse/GEODE-10264 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.14.4 >Reporter: Dave Barnes >Priority: Major > > Community member John Martin reported: > We need to remove the "Connect to the server from your application" section > from this page please: > https://geode.apache.org/docs/guide/114/getting_started/intro_to_clients.html > it is not accurate, and was a section I thought I had deleted before > submitting, but apparently I had not. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10258. - Fix Version/s: 1.15.0 Resolution: Fixed > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10039) BucketProfiles can be stale in rare cases.
[ https://issues.apache.org/jira/browse/GEODE-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10039: Fix Version/s: 1.15.0 > BucketProfiles can be stale in rare cases. > -- > > Key: GEODE-10039 > URL: https://issues.apache.org/jira/browse/GEODE-10039 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.15.0 >Reporter: Mark Hanson >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0 > > > In the case when a server is starting as a member of a partitioned region > during a rebalance, it is possible for the the starting server to not get a > profile removal for a bucket that has been relocated. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528371#comment-17528371 ] Donal Evans commented on GEODE-10258: - This is a test issue caused by an await being used with a slightly incorrect type of assertion. > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10258: --- Assignee: Donal Evans > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10258: Affects Version/s: 1.15.0 > CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > -- > > Key: GEODE-10258 > URL: https://issues.apache.org/jira/browse/GEODE-10258 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > > Task :geode-core:distributedTest > ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition defined as > a lambda expression in > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > within 5 minutes. > at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) > 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:985) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) > Caused by: > org.mockito.exceptions.verification.TooManyActualInvocations: > cacheObserver.afterSettingDiskRef(); > Wanted 1 time: > -> at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > But was 2 times: > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > -> at > org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) > at > org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
[ https://issues.apache.org/jira/browse/GEODE-10258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10258: Description: > Task :geode-core:distributedTest ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest cacheObserver.afterSettingDiskRef(); Wanted 1 time: -> at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) But was 2 times: -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) within 5 minutes. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) 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:985) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) Caused by: org.mockito.exceptions.verification.TooManyActualInvocations: cacheObserver.afterSettingDiskRef(); Wanted 1 time: -> at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) But was 2 times: -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) was: https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14769373 found > Task :geode-core:distributedTest ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED org.awaitility.core.ConditionTimeoutException: Assertion condition defined as a lambda expression in org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest cacheObserver.afterSettingDiskRef(); Wanted 1 time: -> at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) But was 2 times: -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) within 5 minutes. at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167) 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:985) at org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.doConcurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:161) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.concurrentNetSearchGetAndClear(ClearDuringNetSearchOplogRegressionTest.java:145) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.testQueryGetWithClear(ClearDuringNetSearchOplogRegressionTest.java:105) Caused by: org.mockito.exceptions.verification.TooManyActualInvocations: cacheObserver.afterSettingDiskRef(); Wanted 1 time: -> at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) But was 2 times: -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) -> at org.apache.geode.internal.cache.DiskRegion.setClearCountReference(DiskRegion.java:622) at org.apache.geode.internal.cache.ClearDuringNetSearchOplogRegressionTest.lambda$doConcurrentNetSearchGetAndClear$0(ClearDuringNetSearchOplogRegressionTest.java:161) > CI:
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10228:
Affects Version/s: 1.15.0
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> 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:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10228:
Fix Version/s: (was: 1.15.0)
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> 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:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10256: Labels: pull-request-available (was: needsTriage pull-request-available) > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Affects Versions: 1.15.0 >Reporter: Masaki Yamakawa >Priority: Minor > Labels: pull-request-available > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10256) HttpSessionListener is not working
[ https://issues.apache.org/jira/browse/GEODE-10256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10256: Affects Version/s: 1.15.0 > HttpSessionListener is not working > -- > > Key: GEODE-10256 > URL: https://issues.apache.org/jira/browse/GEODE-10256 > Project: Geode > Issue Type: Bug > Components: expiration, http session >Affects Versions: 1.15.0 >Reporter: Masaki Yamakawa >Priority: Minor > Labels: needsTriage, pull-request-available > > I am using "HTTP Session Management Module for Tomcat". > When data managed in a session expires, I want to use HttpSessionListener to > handle the deletion of the associated data. > However, the sessionDestroyed method is not called when the session expires. > When session expiration is enabled, > org.apache.geode.modules.util.SessionCustomExpiry is set in all CacheServers > and Clients. > And when expiration occurs, ExpirationAction.DESTROY is executed. > DESTROY is executed on all CacheServers and clients at about the same time, > and the result of the deletion on the CacheServer is propagated to clients. > At that time, the operation type of the message sent from the CacheServer to > clients is DESTROY. > SessionExpirationCacheListener is set in the client, but > HttpSessionListener#sessionDestroyed will only be executed if > Operation.EXPIRE_DESTROY. > HttpSessionListener#sessionDestroyed is executed if the expiration process is > run first on the client side, but HttpSessionListener#sessionDestroyed is > executed if the CacheServer's DESTROY event is received first. > sessionDestroyed is not executed. > We should send the EXPIRE_DESTROY event from CacheServer, but I think this > has a big impact. > Therefore, I have introduced a Java system property that delays expiration > processing on the CacheServer. > By setting this, HttpSessionListener#sessionDestroyed will surely be executed > by delaying the server-side expiration processing rather than the client's > expiration processing. > Also, if this system property is not set, the behavior will be the same as > the current. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525866#comment-17525866
]
Donal Evans edited comment on GEODE-9880 at 4/21/22 5:18 PM:
-
[~agingade] Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
was (Author: donalevans):
@ginga Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525866#comment-17525866
]
Donal Evans commented on GEODE-9880:
@ginga Following discussion with team members, the questions above were
answered as follows:
Unconditional construction of an SNIHostName is a topic that needs further
discussion, and if deemed to be something we want to avoid, a new ticket will
be created.
Name resolution is required for a valid configuration. In order to support the
use case described here, where clients are not able to resolve hostnames into
IP addresses or vice versa, a significant amount of additional testing would be
required, and would potentially need a lot of code changes. This is not
something we intend to support.
As such, it's recommended that this ticket be closed as "workaround" or "will
not fix" and the "blocks-1.15.0" label be removed.
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9880:
---
Labels: blocks-1.12.10 blocks-1.15.0 membership (was: blocks-1.12.10
blocks-1.15.0 membership pull-request-available)
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525158#comment-17525158
]
Donal Evans edited comment on GEODE-10248 at 4/20/22 6:07 PM:
--
This failure is due to a false positive in the {{LogConsumer.java}} class where
the pattern {{{}[^\d]{\d+{, referred to in the code as
{{MALFORMED_I18N_MESSAGE}} matches what is logged as a result of the management
requests from creating the deployment on the client. Specifically, the portions
of the logged output {{?\{6}}} and {{T\{6}}} match the pattern and cause the
log checking to falsely flag the message as suspect.
was (Author: donalevans):
This failure is due to a false positive in the {{LogConsumer.java}} class where
the pattern {{[^\d]\{\d+\}}}, referred to in the code as
{{MALFORMED_I18N_MESSAGE}} matches what is logged as a result of the management
requests from creating the deployment on the client. Specifically, the portions
of the logged output {{?{6}}} and {{T{6}}} match the pattern and cause the log
checking to falsely flag the message as suspect.
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
[jira] [Commented] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17525158#comment-17525158
]
Donal Evans commented on GEODE-10248:
-
This failure is due to a false positive in the {{LogConsumer.java}} class where
the pattern {{[^\d]\{\d+\}}}, referred to in the code as
{{MALFORMED_I18N_MESSAGE}} matches what is logged as a result of the management
requests from creating the deployment on the client. Specifically, the portions
of the logged output {{?{6}}} and {{T{6}}} match the pattern and cause the log
checking to falsely flag the message as suspect.
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
>
[jira] [Updated] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10248:
Affects Version/s: 1.15.0
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
> at
> org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
> at
> org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
> at
> org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Updated] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
[
https://issues.apache.org/jira/browse/GEODE-10248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10248:
Description:
> Task :geode-assembly:distributedTest
DeployToMultiGroupDUnitTest > executionError FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 571
$??http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650107916/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650107916/distributedtestfiles-openjdk8-1.15.0-build..tgz
was:
Found in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293
> Task :geode-assembly:distributedTest
DeployToMultiGroupDUnitTest > executionError FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm0.log' at line 571
$??http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-results/distributedTest/1650107916/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build./test-artifacts/1650107916/distributedtestfiles-openjdk8-1.15.0-build..tgz
> CI: DeployToMultiGroupDUnitTest encountered suspect string
> --
>
> Key: GEODE-10248
> URL: https://issues.apache.org/jira/browse/GEODE-10248
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> > Task :geode-assembly:distributedTest
> DeployToMultiGroupDUnitTest > executionError FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 571
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> ---YMBX204KTK7fmoVc8vVmUZOfJOmATtYGRLlAK
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 592
>
> $??
> ???PK???L?Tk??6??Class1.classPK???L?T{6}?
> ?timestampPK??u?
> --w3iZZ1eYF3P3Eh2pe2x4sTm2w24zOxfn2XIcRWX1
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.after(ClusterStartupRule.java:183)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.access$100(ClusterStartupRule.java:70)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:141)
> at
> org.apache.geode.test.junit.rules.DescribedExternalResource$1.evaluate(DescribedExternalResource.java:40)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
> at
> org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
> at
> org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
> at
>
[jira] [Resolved] (GEODE-10247) CI: spring-compatibility-test compile failure
[ https://issues.apache.org/jira/browse/GEODE-10247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10247. - Resolution: Invalid This failure was seen in a non-open-source pipeline and so should not have a GEODE ticket associated with it. > CI: spring-compatibility-test compile failure > - > > Key: GEODE-10247 > URL: https://issues.apache.org/jira/browse/GEODE-10247 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage, redis-triage > > It's found in > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14671910 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643293 > https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14643323 > ERROR] Failed to execute goal > org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (java-compile) > on project spring-data-geode: Compilation failure: Compilation failure: > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[103,43] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_BIND_ADDRESS > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[104,38] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_ENABLED > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[105,35] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_PORT > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[106,47] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_REDUNDANT_COPIES > [ERROR] location: interface ConfigurationProperties > [ERROR] > /home/geode/spring-data-geode/spring-data-geode/src/main/java/org/springframework/data/gemfire/GemFireProperties.java:[107,39] > error: cannot find symbol > [ERROR] symbol: variable GEODE_FOR_REDIS_USERNAME > [ERROR] location: interface ConfigurationProperties -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9880) Cluster with multiple locators in an environment with no host name resolution, leads to null pointer exception
[
https://issues.apache.org/jira/browse/GEODE-9880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524636#comment-17524636
]
Donal Evans commented on GEODE-9880:
Some preliminary findings and questions following investigation of this issue
and talking with [~burcham], who knows membership code better than Patrick or
me:
On the client, if we have a locator with only an IP address defined and the
same locator is returned in the locator response with only a hostname defined,
then it is not possible to detect the duplicate without either a forward or
reverse lookup using DNS. Because of this, there is no way to prevent the
hostname-only locator from being added to the list of locators on the client
and then being used and causing the NPE first described.
If hostname-for-clients is configured and set to be an IP address, we follow
the code path shown in [the stack trace in this
comment|https://issues.apache.org/jira/browse/GEODE-9880?focusedCommentId=17460501=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17460501].
SNIHostName requires a valid domain name to be passed into the constructor in
SocketCreator. We attempt to resolve IP addresses to hostnames prior to
invoking the SNIHostName constructor, but if we can't, then we use the IP
address as a hostname. For IPv4, this succeeds, because the format of an IPv4
address is the same as the format of a valid domain name (characters separated
by periods), and so we're able to create the SNIHostName and set it (even
though we may not be using SNI). For IPv6, the constructor will throw, as seen
in the above stack trace.
>From 1.14 onward, the code in both these areas has been reworked
>significantly, so it appears that the originally described NPE may not be
>possible, although the client may still be unable to contact the locator or
>hit an exception elsewhere.
Questions:
Should we make the SNIHostName use conditional on whether you're actually using
SNI? This might allow the hostname-for-clients workaround to work for IPv6
environments, but might not solve the problem if the user wanted to use SNI
*and* could not resolve hostnames to IP addresses or vice versa on the client.
Should working name resolution be required in all cases? Is it a valid
configuration of Geode to allow clients to connect to a cluster without being
able to access the DNS used by members of the cluster?
> Cluster with multiple locators in an environment with no host name
> resolution, leads to null pointer exception
> --
>
> Key: GEODE-9880
> URL: https://issues.apache.org/jira/browse/GEODE-9880
> Project: Geode
> Issue Type: Bug
> Components: locator, membership
>Affects Versions: 1.12.5
>Reporter: Tigran Ghahramanyan
>Assignee: Patrick Johnsn
>Priority: Major
> Labels: blocks-1.12.10, blocks-1.15.0, membership,
> pull-request-available
>
> In our use case we have two locators that are initially configured with IP
> addresses, but _AutoConnectionSourceImpl.UpdateLocatorList()_ flow keeps on
> adding their corresponding host names to the locators list, while these host
> names are not resolvable.
> Later in {_}AutoConnectionSourceImpl.queryLocators(){_}, whenever a client
> tries to use such non resolvable host name to connect to a locator it tries
> to establish a connection to {_}socketaddr=0.0.0.0{_}, as written in
> {_}SocketCreator.connect(){_}. Which seems strange.
> Then, if there is no locator running on the same host, the next locator in
> the list is contacted, until reaching a locator contact configured with IP
> address - which succeeds eventually.
> But, when there happens to be a locator listening on the same host, then we
> have a null pointer exception in the second line below, because _inetadd=null_
> _socket.connect(sockaddr, Math.max(timeout, 0)); // sockaddr=0.0.0.0,
> connects to a locator listening on the same host_
> _configureClientSSLSocket(socket, inetadd.getHostName(), timeout); // inetadd
> = null_
>
> As a result, the cluster comes to a failed state, unable to recover.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10241: Fix Version/s: 1.15.0 > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10241. - Resolution: Fixed > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10241: Affects Version/s: 1.15.0 > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.15.0 >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-10239) CI Failure: FunctionExecutionsTimerClusterTest. timersRecordCountAndTotalTime_ifFunctionExecutedOnReplicateRegionMultipleTimes
[
https://issues.apache.org/jira/browse/GEODE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523784#comment-17523784
]
Donal Evans edited comment on GEODE-10239 at 4/18/22 4:36 PM:
--
Looking at the attached logs, we can see the exact same message seen in
GEODE-10184 about the status file being blank:
{code:java}
[info 2022/04/14 22:28:10.749 GMT tid=0x29] (3) Executing -
start server --name=server2 --groups=server2
--dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2
--server-port=20004 --locators=localhost[20001]
--classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
[info 2022/04/14 22:28:10.749 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x2a] Status file
'C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status'
is blank
[error 2022/04/14 22:28:18.937 GMT tid=0x2a]
[info 2022/04/14 22:28:18.937 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x46] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{code}
was (Author: donalevans):
Looking at the attached logs, we can see the exact same message seen in
GEODE-10184 about the status file being blank:
{code:java}
[info 2022/04/14 22:28:10.749 GMT tid=0x29] (3) Executing -
start server --name=server2 --groups=server2
--dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2
--server-port=20004 --locators=localhost[20001]
--classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
[info 2022/04/14 22:28:10.749 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x2a] Status file
'C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status'
is blank
[error 2022/04/14 22:28:18.937 GMT tid=0x2a]
[info 2022/04/14 22:28:18.937 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x46] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{code}
> CI Failure: FunctionExecutionsTimerClusterTest.
> timersRecordCountAndTotalTime_ifFunctionExecutedOnReplicateRegionMultipleTimes
> --
>
> Key: GEODE-10239
> URL: https://issues.apache.org/jira/browse/GEODE-10239
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [1b960b883a63b41d: gfsh -e start locator --name=locator
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\locator
> --port=20001 --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20002 -e
> start server --name=server1 --groups=server1
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server1
> --server-port=20003 --locators=localhost[20001]
> --classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
> -e start server --name=server2 --groups=server2
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2
> --server-port=20004 --locators=localhost[20001]
> --classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
> -e create region --type=REPLICATE --name=ReplicateRegion -e create region
> --type=PARTITION --groups=server1 --name=PartitionRegion]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129)
> at
>
[jira] [Resolved] (GEODE-10239) CI Failure: FunctionExecutionsTimerClusterTest. timersRecordCountAndTotalTime_ifFunctionExecutedOnReplicateRegionMultipleTimes
[
https://issues.apache.org/jira/browse/GEODE-10239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10239.
-
Resolution: Duplicate
Looking at the attached logs, we can see the exact same message seen in
GEODE-10184 about the status file being blank:
{code:java}
[info 2022/04/14 22:28:10.749 GMT tid=0x29] (3) Executing -
start server --name=server2 --groups=server2
--dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2
--server-port=20004 --locators=localhost[20001]
--classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
[info 2022/04/14 22:28:10.749 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x2a] Status file
'C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status'
is blank
[error 2022/04/14 22:28:18.937 GMT tid=0x2a]
[info 2022/04/14 22:28:18.937 GMT tid=0x29]
[error 2022/04/14 22:28:18.937 GMT tid=0x46] Unable to control process with
C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2\vf.gf.server.status.
Please add tools.jar from JDK to classpath for improved process control.
{code}
> CI Failure: FunctionExecutionsTimerClusterTest.
> timersRecordCountAndTotalTime_ifFunctionExecutedOnReplicateRegionMultipleTimes
> --
>
> Key: GEODE-10239
> URL: https://issues.apache.org/jira/browse/GEODE-10239
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [1b960b883a63b41d: gfsh -e start locator --name=locator
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\locator
> --port=20001 --http-service-port=0 --J=-Dgemfire.jmx-manager-port=20002 -e
> start server --name=server1 --groups=server1
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server1
> --server-port=20003 --locators=localhost[20001]
> --classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
> -e start server --name=server2 --groups=server2
> --dir=C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\server2
> --server-port=20004 --locators=localhost[20001]
> --classpath=C:\Users\geode\AppData\Local\Temp\junit9105142661258454550\metrics-publishing-service.jar;C:\Users\geode\AppData\Local\Temp\junit5459156941691927505\functions.jar
> -e create region --type=REPLICATE --name=ReplicateRegion -e create region
> --type=PARTITION --groups=server1 --name=PartitionRegion]]
> expected: 0
> but was: 1
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:129)
> at
> org.apache.geode.metrics.function.executions.FunctionExecutionsTimerClusterTest.setUp(FunctionExecutionsTimerClusterTest.java:117)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.RunBefores.invokeMethod(RunBefores.java:33)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at
[jira] [Resolved] (GEODE-2428) Add support for LinkedHashMap in DataSerializer
[ https://issues.apache.org/jira/browse/GEODE-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-2428. Resolution: Fixed This was fixed in 2017 but the ticket was never closed. > Add support for LinkedHashMap in DataSerializer > --- > > Key: GEODE-2428 > URL: https://issues.apache.org/jira/browse/GEODE-2428 > Project: Geode > Issue Type: Improvement >Reporter: Avinash >Assignee: Avinash >Priority: Major > > DataSerializer should also support serialization and de-serialization of > DataSerializer -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-888) Change build to fail if javadocs generates any warnings
[ https://issues.apache.org/jira/browse/GEODE-888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-888. --- Fix Version/s: 1.15.0 Resolution: Fixed > Change build to fail if javadocs generates any warnings > --- > > Key: GEODE-888 > URL: https://issues.apache.org/jira/browse/GEODE-888 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Kirk Lund >Priority: Major > Labels: javadocs > Fix For: 1.15.0 > > > See GEODE-805. After javadoc warnings are fixed, the build should be changed > to fail if javadocs generates any warnings (for problems such as malformed > tags). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-3322) geode-core:javadoc is generating warnings
[
https://issues.apache.org/jira/browse/GEODE-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-3322.
Fix Version/s: 1.15.0
Resolution: Fixed
> geode-core:javadoc is generating warnings
> -
>
> Key: GEODE-3322
> URL: https://issues.apache.org/jira/browse/GEODE-3322
> Project: Geode
> Issue Type: Bug
> Components: build, membership
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0, 1.3.0
>
>
> {noformat}
> :geode-core:javadoc
> /Users/klund/dev/gemfire/open/geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/HostAddress.java:45:
> warning - @return tag has no arguments.
> 1 warning
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10023. - Fix Version/s: 1.15.0 Resolution: Fixed > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Affects Versions: 1.15.0 >Reporter: Kirk Lund >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > This ticket specifically refers to the javadoc warnings in the build output > about various broken links and similar details about management classes and > security classed that are generated when building Geode on the command-line > with gradle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10023: Affects Version/s: 1.15.0 > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Affects Versions: 1.15.0 >Reporter: Kirk Lund >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > This ticket specifically refers to the javadoc warnings in the build output > about various broken links and similar details about management classes and > security classed that are generated when building Geode on the command-line > with gradle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError
[
https://issues.apache.org/jira/browse/GEODE-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10222.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> Null memberID in GII of persistent region with concurrent region destroy
> causes AssertionError
> --
>
> Key: GEODE-10222
> URL: https://issues.apache.org/jira/browse/GEODE-10222
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> The below stack trace was observed while concurrent region creates and
> destroys were being performed on a persistent replicated region:
> {noformat}
> java.lang.AssertionError: Member id should not be null for persistent version
> tags
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at Remote Member 'localhost(server2:13075):41003' in
> java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
> The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not
> handled by any of the calling methods, which leads to the GII failing without
> attempting to retry, and does not decrement the getInitialImagesInProgress
> stat.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10223:
Description:
{noformat}
> Task :geode-for-redis:integrationTest
BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
java.lang.AssertionError:
Expecting actual:
1.0
to be less than:
1.0
at
org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
Test report artifacts from this job are available at:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
was:
{noformat}
> Task :geode-for-redis:integrationTest
BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
java.lang.AssertionError:
Expecting actual:
1.0
to be less than:
1.0
at
org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Test
report artifacts from this job are available
at:http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10023: --- Assignee: Donal Evans > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Reporter: Kirk Lund >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10224) geode-connectors:acceptanceTest task hang in CI with no tests started
[
https://issues.apache.org/jira/browse/GEODE-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10224:
Description:
A hang was observed in a CI run of acceptance-test-openjdk8:
{noformat}
20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
20:37:55> Task :geode-assembly:acceptanceTest
21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-common:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-common:acceptanceTest NO-SOURCE
21:44:13> Task :geode-concurrency-test:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-concurrency-test:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-concurrency-test:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-concurrency-test:acceptanceTest NO-SOURCE
21:44:16> Task :geode-connectors:compileAcceptanceTestJava
21:44:16> Task :geode-connectors:processAcceptanceTestResources
21:44:16> Task :geode-connectors:acceptanceTestClasses
21:44:46> Task :geode-connectors:acceptanceTest
21:44:46
timeout exceeded{noformat}
The geode-common:acceptanceTest task was able to complete normally, but the
test result artifacts for the run, linked below, show no
acceptanceTest-progress.txt in the {{geode-connectors/build/acceptanceTest}}
directory, and no output in
{{{}geode-connectors/build/test-results/acceptanceTest/binary/output.bin{}}},
indicating that no tests from geode-connectors were able to start.
A subsequent run of the job passed with no issue.
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-results/acceptanceTest/1649316934/]
={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
Test report artifacts from this job are available at:
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-artifacts/1649316934/acceptancetestfiles-openjdk8-1.15.0-build.1082.tgz]
was:
A hang was observed in a CI run of acceptance-test-openjdk8:
{noformat}
20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
20:37:55> Task :geode-assembly:acceptanceTest
21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-common:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-common:acceptanceTest NO-SOURCE
21:44:13> Task :geode-concurrency-test:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-concurrency-test:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-concurrency-test:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-concurrency-test:acceptanceTest NO-SOURCE
21:44:16> Task :geode-connectors:compileAcceptanceTestJava
21:44:16> Task :geode-connectors:processAcceptanceTestResources
21:44:16> Task :geode-connectors:acceptanceTestClasses
21:44:46> Task :geode-connectors:acceptanceTest
21:44:46
timeout exceeded{noformat}
The geode-common:acceptanceTest task was able to complete normally, but the
test result artifacts for the run, linked below, show no
acceptanceTest-progress.txt in the {{geode-connectors/build/acceptanceTest}}
directory, and no output in
{{{}geode-connectors/build/test-results/acceptanceTest/binary/output.bin{}}},
indicating that no tests from geode-connectors were able to start.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-results/acceptanceTest/1649316934/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-artifacts/1649316934/acceptancetestfiles-openjdk8-1.15.0-build.1082.tgz
> geode-connectors:acceptanceTest task hang in CI with no tests started
> -
>
> Key: GEODE-10224
> URL: https://issues.apache.org/jira/browse/GEODE-10224
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> A hang was observed in a CI run of acceptance-test-openjdk8:
> {noformat}
> 20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
> 20:37:55> Task :geode-assembly:acceptanceTest
> 21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
> 21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
>
[jira] [Created] (GEODE-10224) geode-connectors:acceptanceTest task hang in CI with no tests started
Donal Evans created GEODE-10224:
---
Summary: geode-connectors:acceptanceTest task hang in CI with no
tests started
Key: GEODE-10224
URL: https://issues.apache.org/jira/browse/GEODE-10224
Project: Geode
Issue Type: Bug
Components: ci
Affects Versions: 1.15.0
Reporter: Donal Evans
A hang was observed in a CI run of acceptance-test-openjdk8:
{noformat}
20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
20:37:55> Task :geode-assembly:acceptanceTest
21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-common:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-common:acceptanceTest NO-SOURCE
21:44:13> Task :geode-concurrency-test:compileAcceptanceTestJava NO-SOURCE
21:44:13> Task :geode-concurrency-test:processAcceptanceTestResources NO-SOURCE
21:44:13> Task :geode-concurrency-test:acceptanceTestClasses UP-TO-DATE
21:44:13> Task :geode-concurrency-test:acceptanceTest NO-SOURCE
21:44:16> Task :geode-connectors:compileAcceptanceTestJava
21:44:16> Task :geode-connectors:processAcceptanceTestResources
21:44:16> Task :geode-connectors:acceptanceTestClasses
21:44:46> Task :geode-connectors:acceptanceTest
21:44:46
timeout exceeded{noformat}
The geode-common:acceptanceTest task was able to complete normally, but the
test result artifacts for the run, linked below, show no
acceptanceTest-progress.txt in the {{geode-connectors/build/acceptanceTest}}
directory, and no output in
{{{}geode-connectors/build/test-results/acceptanceTest/binary/output.bin{}}},
indicating that no tests from geode-connectors were able to start.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-results/acceptanceTest/1649316934/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-artifacts/1649316934/acceptancetestfiles-openjdk8-1.15.0-build.1082.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
Donal Evans created GEODE-10223:
---
Summary: BlockingCommandListenerTest > testTimeoutIsAdjusted fails
on Windows due to timeout not changing
Key: GEODE-10223
URL: https://issues.apache.org/jira/browse/GEODE-10223
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
{noformat}
> Task :geode-for-redis:integrationTest
BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
java.lang.AssertionError:
Expecting actual:
1.0
to be less than:
1.0
at
org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=Test
report artifacts from this job are available
at:http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10217:
Description:
The below stack traces were seen in the unit-test-openjdk8 job in the pipeline.
In addition to the two failures shown, multiple other failures due to
{{NoClassDefFoundError}} for {{ThreadLocalRandom}} were also present.
{noformat}
DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
10:19:40org.mockito.exceptions.base.MockitoException:
10:19:40Mockito cannot mock this class: class
org.apache.geode.internal.cache.DiskRegion.
10:19:40
10:19:40If you're not sure why you're getting this error, please report to
the mailing list.
10:19:40
10:19:40
10:19:40Java : 1.8
10:19:40JVM vendor name: BellSoft
10:19:40JVM vendor version : 25.322-b06
10:19:40JVM name : OpenJDK 64-Bit Server VM
10:19:40JVM version: 1.8.0_322-b06
10:19:40JVM info : mixed mode
10:19:40OS name: Linux
10:19:40OS version : 5.4.0-1069-gcp
10:19:40
10:19:40
10:19:40You are seeing this disclaimer because Mockito is configured to
create inlined mocks.
10:19:40You can learn about inline mocks and their limitations under item
#39 of the Mockito class javadoc.
10:19:40
10:19:40Underlying exception :
org.mockito.exceptions.base.MockitoException: Could not modify all classes
[class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at
org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
10:19:40
10:19:40Caused by:
10:19:40org.mockito.exceptions.base.MockitoException: Could not modify
all classes [class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.IllegalStateException:
10:19:40Byte Buddy could not instrument all classes within the
mock's type hierarchy
10:19:40
10:19:40This problem should never occur for javac-compiled classes.
This problem has been observed for classes that are:
10:19:40 - Compiled by older versions of scalac
10:19:40 - Classes that are part of the Android distribution
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
10:19:40at
org.mockito.internal.util.MockUtil.createMock(MockUtil.java:53)
10:19:40at
org.mockito.internal.MockitoCore.mock(MockitoCore.java:96)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1965)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1880)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40
[jira] [Updated] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10217:
Description:
Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
Byte Buddy could not instrument all classes within the mock's type hierarchy.
{noformat}
DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
10:19:40org.mockito.exceptions.base.MockitoException:
10:19:40Mockito cannot mock this class: class
org.apache.geode.internal.cache.DiskRegion.
10:19:40
10:19:40If you're not sure why you're getting this error, please report to
the mailing list.
10:19:40
10:19:40
10:19:40Java : 1.8
10:19:40JVM vendor name: BellSoft
10:19:40JVM vendor version : 25.322-b06
10:19:40JVM name : OpenJDK 64-Bit Server VM
10:19:40JVM version: 1.8.0_322-b06
10:19:40JVM info : mixed mode
10:19:40OS name: Linux
10:19:40OS version : 5.4.0-1069-gcp
10:19:40
10:19:40
10:19:40You are seeing this disclaimer because Mockito is configured to
create inlined mocks.
10:19:40You can learn about inline mocks and their limitations under item
#39 of the Mockito class javadoc.
10:19:40
10:19:40Underlying exception :
org.mockito.exceptions.base.MockitoException: Could not modify all classes
[class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at
org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
10:19:40
10:19:40Caused by:
10:19:40org.mockito.exceptions.base.MockitoException: Could not modify
all classes [class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.IllegalStateException:
10:19:40Byte Buddy could not instrument all classes within the
mock's type hierarchy
10:19:40
10:19:40This problem should never occur for javac-compiled classes.
This problem has been observed for classes that are:
10:19:40 - Compiled by older versions of scalac
10:19:40 - Classes that are part of the Android distribution
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
10:19:40at
org.mockito.internal.util.MockUtil.createMock(MockUtil.java:53)
10:19:40at
org.mockito.internal.MockitoCore.mock(MockitoCore.java:96)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1965)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1880)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.ExceptionInInitializerError
10:19:40at
[jira] [Updated] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10217:
Summary: NullPointerException or NoClassDefFoundError in ThreadLocalRandom
causes multiple test failures (was: Mockito Unable to Mock
org.apache.geode.internal.cache.DiskRegion)
> NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes
> multiple test failures
> ---
>
> Key: GEODE-10217
> URL: https://issues.apache.org/jira/browse/GEODE-10217
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Reporter: Patrick Johnsn
>Priority: Major
>
> Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
> Byte Buddy could not instrument all classes within the mock's type hierarchy.
> {noformat}
> DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
> 10:19:40org.mockito.exceptions.base.MockitoException:
> 10:19:40Mockito cannot mock this class: class
> org.apache.geode.internal.cache.DiskRegion.
> 10:19:40
> 10:19:40If you're not sure why you're getting this error, please report
> to the mailing list.
> 10:19:40
> 10:19:40
> 10:19:40Java : 1.8
> 10:19:40JVM vendor name: BellSoft
> 10:19:40JVM vendor version : 25.322-b06
> 10:19:40JVM name : OpenJDK 64-Bit Server VM
> 10:19:40JVM version: 1.8.0_322-b06
> 10:19:40JVM info : mixed mode
> 10:19:40OS name: Linux
> 10:19:40OS version : 5.4.0-1069-gcp
> 10:19:40
> 10:19:40
> 10:19:40You are seeing this disclaimer because Mockito is configured to
> create inlined mocks.
> 10:19:40You can learn about inline mocks and their limitations under item
> #39 of the Mockito class javadoc.
> 10:19:40
> 10:19:40Underlying exception :
> org.mockito.exceptions.base.MockitoException: Could not modify all classes
> [class org.apache.geode.internal.cache.DiskRegion, interface
> org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
> 10:19:40
> 10:19:40Caused by:
> 10:19:40org.mockito.exceptions.base.MockitoException: Could not
> modify all classes [class org.apache.geode.internal.cache.DiskRegion,
> interface org.apache.geode.internal.cache.persistence.DiskRegionView, class
> org.apache.geode.internal.cache.AbstractDiskRegion]
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40... 1 more
> 10:19:40
> 10:19:40Caused by:
> 10:19:40java.lang.IllegalStateException:
> 10:19:40Byte Buddy could not instrument all classes within the
> mock's type hierarchy
> 10:19:40
> 10:19:40This problem should never occur for javac-compiled
> classes. This problem has been observed for classes that are:
> 10:19:40 - Compiled by older versions of scalac
> 10:19:40 - Classes that are part of the Android distribution
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
> 10:19:40at
> net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
> 10:19:40at
> net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
> 10:19:40at
> org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
>
[jira] [Updated] (GEODE-10217) NullPointerException or NoClassDefFoundError in ThreadLocalRandom causes multiple test failures
[
https://issues.apache.org/jira/browse/GEODE-10217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10217:
Description:
Mokito cannot mock DiskRegion, DiskRegionView, and AbstractDiskRegion because
Byte Buddy could not instrument all classes within the mock's type hierarchy.
{noformat}
DiskEntryHelperTest > doSynchronousWriteReturnsTrueWhenDiskRegionIsSync FAILED
10:19:40org.mockito.exceptions.base.MockitoException:
10:19:40Mockito cannot mock this class: class
org.apache.geode.internal.cache.DiskRegion.
10:19:40
10:19:40If you're not sure why you're getting this error, please report to
the mailing list.
10:19:40
10:19:40
10:19:40Java : 1.8
10:19:40JVM vendor name: BellSoft
10:19:40JVM vendor version : 25.322-b06
10:19:40JVM name : OpenJDK 64-Bit Server VM
10:19:40JVM version: 1.8.0_322-b06
10:19:40JVM info : mixed mode
10:19:40OS name: Linux
10:19:40OS version : 5.4.0-1069-gcp
10:19:40
10:19:40
10:19:40You are seeing this disclaimer because Mockito is configured to
create inlined mocks.
10:19:40You can learn about inline mocks and their limitations under item
#39 of the Mockito class javadoc.
10:19:40
10:19:40Underlying exception :
org.mockito.exceptions.base.MockitoException: Could not modify all classes
[class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at
org.apache.geode.internal.cache.entries.DiskEntryHelperTest.(DiskEntryHelperTest.java:44)
10:19:40
10:19:40Caused by:
10:19:40org.mockito.exceptions.base.MockitoException: Could not modify
all classes [class org.apache.geode.internal.cache.DiskRegion, interface
org.apache.geode.internal.cache.persistence.DiskRegionView, class
org.apache.geode.internal.cache.AbstractDiskRegion]
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.IllegalStateException:
10:19:40Byte Buddy could not instrument all classes within the
mock's type hierarchy
10:19:40
10:19:40This problem should never occur for javac-compiled classes.
This problem has been observed for classes that are:
10:19:40 - Compiled by older versions of scalac
10:19:40 - Classes that are part of the Android distribution
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.triggerRetransformation(InlineBytecodeGenerator.java:280)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineBytecodeGenerator.mockClass(InlineBytecodeGenerator.java:213)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.lambda$mockClass$0(TypeCachingBytecodeGenerator.java:47)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:157)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:371)
10:19:40at
net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:179)
10:19:40at
net.bytebuddy.TypeCache$WithInlineExpunction.findOrInsert(TypeCache.java:382)
10:19:40at
org.mockito.internal.creation.bytebuddy.TypeCachingBytecodeGenerator.mockClass(TypeCachingBytecodeGenerator.java:40)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMockType(InlineDelegateByteBuddyMockMaker.java:389)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.doCreateMock(InlineDelegateByteBuddyMockMaker.java:349)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineDelegateByteBuddyMockMaker.createMock(InlineDelegateByteBuddyMockMaker.java:328)
10:19:40at
org.mockito.internal.creation.bytebuddy.InlineByteBuddyMockMaker.createMock(InlineByteBuddyMockMaker.java:56)
10:19:40at
org.mockito.internal.util.MockUtil.createMock(MockUtil.java:53)
10:19:40at
org.mockito.internal.MockitoCore.mock(MockitoCore.java:96)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1965)
10:19:40at org.mockito.Mockito.mock(Mockito.java:1880)
10:19:40... 1 more
10:19:40
10:19:40Caused by:
10:19:40java.lang.ExceptionInInitializerError
10:19:40at
[jira] [Updated] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError
[
https://issues.apache.org/jira/browse/GEODE-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10222:
Labels: blocks-1.15.0 (was: needsTriage)
> Null memberID in GII of persistent region with concurrent region destroy
> causes AssertionError
> --
>
> Key: GEODE-10222
> URL: https://issues.apache.org/jira/browse/GEODE-10222
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> The below stack trace was observed while concurrent region creates and
> destroys were being performed on a persistent replicated region:
> {noformat}
> java.lang.AssertionError: Member id should not be null for persistent version
> tags
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at Remote Member 'localhost(server2:13075):41003' in
> java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
> The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not
> handled by any of the calling methods, which leads to the GII failing without
> attempting to retry, and does not decrement the getInitialImagesInProgress
> stat.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError
[
https://issues.apache.org/jira/browse/GEODE-10222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reassigned GEODE-10222:
---
Assignee: Donal Evans
> Null memberID in GII of persistent region with concurrent region destroy
> causes AssertionError
> --
>
> Key: GEODE-10222
> URL: https://issues.apache.org/jira/browse/GEODE-10222
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: needsTriage
>
> The below stack trace was observed while concurrent region creates and
> destroys were being performed on a persistent replicated region:
> {noformat}
> java.lang.AssertionError: Member id should not be null for persistent version
> tags
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at Remote Member 'localhost(server2:13075):41003' in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
> at Remote Member 'localhost(server2:13075):41003' in
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at Remote Member 'localhost(server2:13075):41003' in
> java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
> The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not
> handled by any of the calling methods, which leads to the GII failing without
> attempting to retry, and does not decrement the getInitialImagesInProgress
> stat.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10222) Null memberID in GII of persistent region with concurrent region destroy causes AssertionError
Donal Evans created GEODE-10222:
---
Summary: Null memberID in GII of persistent region with concurrent
region destroy causes AssertionError
Key: GEODE-10222
URL: https://issues.apache.org/jira/browse/GEODE-10222
Project: Geode
Issue Type: Bug
Affects Versions: 1.15.0
Reporter: Donal Evans
The below stack trace was observed while concurrent region creates and destroys
were being performed on a persistent replicated region:
{noformat}
java.lang.AssertionError: Member id should not be null for persistent version
tags
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.internal.cache.versions.DiskVersionTag.replaceNullIDs(DiskVersionTag.java:47)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:975)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1312)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:214)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2858)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:197)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:190)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
at Remote Member 'localhost(server2:13075):41003' in
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at Remote Member 'localhost(server2:13075):41003' in
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:444)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.distributed.internal.ClusterOperationExecutors.doHighPriorityThread(ClusterOperationExecutors.java:402)
at Remote Member 'localhost(server2:13075):41003' in
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at Remote Member 'localhost(server2:13075):41003' in
java.lang.Thread.run(Thread.java:748)
at
org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:90)
at
org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:562)
at
org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1249)
at
org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986){noformat}
The {{AssertionError}} thrown by {{DiskVersionTag.replaceNullIDs()}} is not
handled by any of the calling methods, which leads to the GII failing without
attempting to retry, and does not decrement the getInitialImagesInProgress stat.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10204) Add unit test cases for SizeableByteArrayList
[
https://issues.apache.org/jira/browse/GEODE-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10204:
Description: For example, {{clearSublist()}} was added for LTRIM support
and needs unit tests. Any public method that does not just call the {{super()}}
method on {{LinkedList}} should have coverage. (was: For example,
clearSublist() was added for LTRIM support and needs tests. Any public method
without tests should have coverage.)
> Add unit test cases for SizeableByteArrayList
> -
>
> Key: GEODE-10204
> URL: https://issues.apache.org/jira/browse/GEODE-10204
> Project: Geode
> Issue Type: Test
> Components: redis
>Reporter: Ray Ingles
>Priority: Major
>
> For example, {{clearSublist()}} was added for LTRIM support and needs unit
> tests. Any public method that does not just call the {{super()}} method on
> {{LinkedList}} should have coverage.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10204) Add unit test cases for SizeableByteArrayList
[
https://issues.apache.org/jira/browse/GEODE-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10204:
Affects Version/s: 1.15.0
> Add unit test cases for SizeableByteArrayList
> -
>
> Key: GEODE-10204
> URL: https://issues.apache.org/jira/browse/GEODE-10204
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Priority: Major
>
> For example, {{clearSublist()}} was added for LTRIM support and needs unit
> tests. Any public method that does not just call the {{super()}} method on
> {{LinkedList}} should have coverage.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10204) Add unit test cases for SizeableByteArrayList
[ https://issues.apache.org/jira/browse/GEODE-10204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10204: Summary: Add unit test cases for SizeableByteArrayList (was: Add test cases for SizeableByteArray) > Add unit test cases for SizeableByteArrayList > - > > Key: GEODE-10204 > URL: https://issues.apache.org/jira/browse/GEODE-10204 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Ray Ingles >Priority: Major > > For example, clearSublist() was added for LTRIM support and needs tests. Any > public method without tests should have coverage. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-10166. - Fix Version/s: 1.15.0 Resolution: Fixed > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9983) Implement RPOPLPUSH Command
[ https://issues.apache.org/jira/browse/GEODE-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans resolved GEODE-9983. Fix Version/s: 1.15.0 Resolution: Fixed > Implement RPOPLPUSH Command > --- > > Key: GEODE-9983 > URL: https://issues.apache.org/jira/browse/GEODE-9983 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Implement the [RPOPLPUSH|https://redis.io/commands/RPOPLPUSH] command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary
[
https://issues.apache.org/jira/browse/GEODE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10171:
Description:
For SADD, which may or may not modify the data in the region depending on
whether the member being added is already present in the set, the version in
AbstractRedisData is updated regardless of whether a Delta is sent to the
secondary. This can lead to the version on the primary wrapping around to be
equal to the version on the secondary, which means that if a delta is sent, it
will not be applied on the secondary, leading to potential data loss.
Below is a test to show this behaviour:
{code:java}
@Test
public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
String originalMember = "fixedMemberName";
String key = clusterStartUp.getKeyOnServer("tag", 1);
// Version of primary = 0
// Version of secondary = 0
jedis.sadd(key, originalMember);
// No changes are made to the set, since adding an already existing member
doesn't modify it
// Version of primary wraps around back to -1
// Version of secondary doesn't change because we don't send a delta
for (int i = 0; i < 255; ++i) {
jedis.sadd(key, originalMember);
}
String newMember = "aNewMemberName";
// Version of primary = 0
// Version of secondary = 0, delta is not applied
jedis.sadd(key, newMember);
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
clusterStartUp.crashVM(1); // kill primary server
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
} {code}
The example here uses SADD, but potentially, any command that can be a no-op
and uses a versioned Delta is at risk of hitting this. All commands should be
checked to ensure they're not vulnerable to this bug.
was:
For SADD, which may or may not modify the data in the region depending on
whether the member being added is already present in the set, the version in
AbstractRedisData is updated regardless of whether a Delta is sent to the
secondary. This can lead to the version on the primary wrapping around to be
equal to the version on the secondary, which means that if a delta is sent, it
will not be applied on the secondary, leading to potential data loss.
Below is a test to show this behaviour:
{code:java}
@Test
public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
String originalMember = "fixedMemberName";
String key = clusterStartUp.getKeyOnServer("lrem", 1);
// Version of primary = 0
// Version of secondary = 0
jedis.sadd(key, originalMember);
// No changes are made to the set, since adding an already existing member
doesn't modify it
// Version of primary wraps around back to -1
// Version of secondary doesn't change because we don't send a delta
for (int i = 0; i < 255; ++i) {
jedis.sadd(key, originalMember);
}
String newMember = "aNewMemberName";
// Version of primary = 0
// Version of secondary = 0, delta is not applied
jedis.sadd(key, newMember);
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
clusterStartUp.crashVM(1); // kill primary server
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
} {code}
> AbstractRedisData version being incremented for no-op operations can lead to
> delta not being applied on secondary
> -
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> For SADD, which may or may not modify the data in the region depending on
> whether the member being added is already present in the set, the version in
> AbstractRedisData is updated regardless of whether a Delta is sent to the
> secondary. This can lead to the version on the primary wrapping around to be
> equal to the version on the secondary, which means that if a delta is sent,
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
> String originalMember = "fixedMemberName";
> String key = clusterStartUp.getKeyOnServer("tag", 1);
>
> // Version of primary = 0
> // Version of secondary = 0
> jedis.sadd(key, originalMember);
> // No changes are made to the set, since adding an already existing member
> doesn't modify it
> // Version of primary wraps around back to -1
> // Version of secondary doesn't change because we don't send a delta
> for (int i = 0; i < 255; ++i) {
>
[jira] [Updated] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary
[
https://issues.apache.org/jira/browse/GEODE-10171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10171:
Labels: blocks-1.15.0 (was: needsTriage)
> AbstractRedisData version being incremented for no-op operations can lead to
> delta not being applied on secondary
> -
>
> Key: GEODE-10171
> URL: https://issues.apache.org/jira/browse/GEODE-10171
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> For SADD, which may or may not modify the data in the region depending on
> whether the member being added is already present in the set, the version in
> AbstractRedisData is updated regardless of whether a Delta is sent to the
> secondary. This can lead to the version on the primary wrapping around to be
> equal to the version on the secondary, which means that if a delta is sent,
> it will not be applied on the secondary, leading to potential data loss.
> Below is a test to show this behaviour:
> {code:java}
> @Test
> public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
> String originalMember = "fixedMemberName";
> String key = clusterStartUp.getKeyOnServer("lrem", 1);
>
> // Version of primary = 0
> // Version of secondary = 0
> jedis.sadd(key, originalMember);
> // No changes are made to the set, since adding an already existing member
> doesn't modify it
> // Version of primary wraps around back to -1
> // Version of secondary doesn't change because we don't send a delta
> for (int i = 0; i < 255; ++i) {
> jedis.sadd(key, originalMember);
> }
> String newMember = "aNewMemberName";
> // Version of primary = 0
> // Version of secondary = 0, delta is not applied
> jedis.sadd(key, newMember);
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> clusterStartUp.crashVM(1); // kill primary server
> assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
> newMember);
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10171) AbstractRedisData version being incremented for no-op operations can lead to delta not being applied on secondary
Donal Evans created GEODE-10171:
---
Summary: AbstractRedisData version being incremented for no-op
operations can lead to delta not being applied on secondary
Key: GEODE-10171
URL: https://issues.apache.org/jira/browse/GEODE-10171
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Donal Evans
For SADD, which may or may not modify the data in the region depending on
whether the member being added is already present in the set, the version in
AbstractRedisData is updated regardless of whether a Delta is sent to the
secondary. This can lead to the version on the primary wrapping around to be
equal to the version on the secondary, which means that if a delta is sent, it
will not be applied on the secondary, leading to potential data loss.
Below is a test to show this behaviour:
{code:java}
@Test
public void deltaVersionOnPrimary_shouldNotUpdate_ifNoDeltaSent() {
String originalMember = "fixedMemberName";
String key = clusterStartUp.getKeyOnServer("lrem", 1);
// Version of primary = 0
// Version of secondary = 0
jedis.sadd(key, originalMember);
// No changes are made to the set, since adding an already existing member
doesn't modify it
// Version of primary wraps around back to -1
// Version of secondary doesn't change because we don't send a delta
for (int i = 0; i < 255; ++i) {
jedis.sadd(key, originalMember);
}
String newMember = "aNewMemberName";
// Version of primary = 0
// Version of secondary = 0, delta is not applied
jedis.sadd(key, newMember);
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
clusterStartUp.crashVM(1); // kill primary server
assertThat(jedis.smembers(key)).containsExactlyInAnyOrder(originalMember,
newMember);
} {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10166: Affects Version/s: 1.15.0 > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
Donal Evans created GEODE-10166: --- Summary: Several tests in geode-dunit are in the "main" source set instead of "distributedTest" Key: GEODE-10166 URL: https://issues.apache.org/jira/browse/GEODE-10166 Project: Geode Issue Type: Bug Components: tests Reporter: Donal Evans The below tests in the geode-dunit module have been incorrectly placed in the "main" directory rather than the "distributedTest" directory, meaning that they are not run as part of pre-checkin or in the pipeline: InternalCacheForClientAccessDUnitTest NestedQueryClassCastExceptionFailureDUnitTest RebalanceCommandDistributedTest They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-10166: Labels: (was: needsTriage) > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10166) Several tests in geode-dunit are in the "main" source set instead of "distributedTest"
[ https://issues.apache.org/jira/browse/GEODE-10166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-10166: --- Assignee: Donal Evans > Several tests in geode-dunit are in the "main" source set instead of > "distributedTest" > -- > > Key: GEODE-10166 > URL: https://issues.apache.org/jira/browse/GEODE-10166 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: needsTriage > > The below tests in the geode-dunit module have been incorrectly placed in the > "main" directory rather than the "distributedTest" directory, meaning that > they are not run as part of pre-checkin or in the pipeline: > InternalCacheForClientAccessDUnitTest > NestedQueryClassCastExceptionFailureDUnitTest > RebalanceCommandDistributedTest > They should be moved to the appropriate directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9983) Implement RPOPLPUSH Command
[ https://issues.apache.org/jira/browse/GEODE-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans reassigned GEODE-9983: -- Assignee: Donal Evans > Implement RPOPLPUSH Command > --- > > Key: GEODE-9983 > URL: https://issues.apache.org/jira/browse/GEODE-9983 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Donal Evans >Priority: Major > > Implement the [RPOPLPUSH|https://redis.io/commands/RPOPLPUSH] command. > > +Acceptance Criteria+ > > The command has been implemented along with appropriate unit and system tests. > > The command has been tested using the redis-cli tool and verified against > native redis. > > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10121:
Description:
The following test (if added to MSetDUnitTest) is intended to show that MSET is
transactional in nature by having the final key to be set throw an exception,
which should roll back the previous set values:
{code:java}
public static final String THROWING_REDIS_STRING_EXCEPTION = "to be ignored";
@Test
public void mset_isTransactional() {
IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
String key1 = hashTag + "key1";
String value1 = "value1";
jedis.set(key1, value1);
String key2 = hashTag + "key2";
String value2 = "value2";
jedis.set(key2, value2);
String throwingRedisStringKey = hashTag + "ThrowingRedisString";
String throwingStringValue = "ThrowingRedisStringValue";
// Put a test version of RedisString directly into the region that throws
if the multi-argument set() is called on it
clusterStartUp.getMember(1).invoke(() -> {
RedisKey throwingKey = new
RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
ThrowingRedisString throwingRedisString = new ThrowingRedisString();
throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
throwingRedisString);
});
String newValue = "should_not_be_set";
assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
assertThat(jedis.get(key1)).isEqualTo(value1);
assertThat(jedis.get(key2)).isEqualTo(value2);
assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
IgnoredException.removeAllExpectedExceptions();
}
static class ThrowingRedisString extends RedisString {
@Override
public void set(Region region, RedisKey key, byte[]
newValue,
SetOptions options) {
throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
}
}{code}
This test fails due to {{key1}} having its value set to {{newValue}} despite
the fact that MSET is supposed to be atomic.
Given the similar implementations each command uses, it is very likely that
MSETNX and SMOVE also show the same behaviour.
was:
The following test (if added to MSetDUnitTest) is intended to show that MSET is
transactional in nature by having the final key to be set throw an exception,
which should roll back the previous set values:
{code:java}
public static final String THROWING_REDIS_STRING_EXCEPTION = "to be ignored";
@Test
public void mset_isTransactional() {
IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
String key1 = hashTag + "key1";
String value1 = "value1";
jedis.set(key1, value1);
String key2 = hashTag + "key2";
String value2 = "value2";
jedis.set(key2, value2);
String throwingRedisStringKey = hashTag + "ThrowingRedisString";
String throwingStringValue = "ThrowingRedisStringValue";
// Put a test version of RedisString directly into the region that throws
if the multi-argument set() is called on it
clusterStartUp.getMember(1).invoke(() -> {
RedisKey throwingKey = new
RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
ThrowingRedisString throwingRedisString = new ThrowingRedisString();
throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
throwingRedisString);
});
String newValue = "should_not_be_set";
assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
assertThat(jedis.get(key1)).isEqualTo(value1);
assertThat(jedis.get(key2)).isEqualTo(value2);
assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
IgnoredException.removeAllExpectedExceptions();
}
static class ThrowingRedisString extends RedisString {
@Override
public void set(Region region, RedisKey key, byte[]
newValue,
SetOptions options) {
throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
}
}{code}
This test fails due to {{key1}} having its value set to {{newValue}} despite
the fact that MSET is supposed to be atomic.
Given the similar implementations each command uses, it is very likely that
RENAME, MSETNX and SMOVE also show the same behaviour.
> Transactional Redis commands are not actually transactional
>
[jira] [Resolved] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10010.
-
Resolution: Fixed
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10121) Transactional Redis commands are not actually transactional
[
https://issues.apache.org/jira/browse/GEODE-10121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10121:
Labels: blocks-1.15.0 (was: needsTriage)
> Transactional Redis commands are not actually transactional
> ---
>
> Key: GEODE-10121
> URL: https://issues.apache.org/jira/browse/GEODE-10121
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Priority: Major
> Labels: blocks-1.15.0
>
> The following test (if added to MSetDUnitTest) is intended to show that MSET
> is transactional in nature by having the final key to be set throw an
> exception, which should roll back the previous set values:
> {code:java}
> public static final String THROWING_REDIS_STRING_EXCEPTION = "to be
> ignored";
>
> @Test
> public void mset_isTransactional() {
> IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
> String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
> String key1 = hashTag + "key1";
> String value1 = "value1";
> jedis.set(key1, value1);
> String key2 = hashTag + "key2";
> String value2 = "value2";
> jedis.set(key2, value2);
> String throwingRedisStringKey = hashTag + "ThrowingRedisString";
> String throwingStringValue = "ThrowingRedisStringValue";
> // Put a test version of RedisString directly into the region that throws
> if the multi-argument set() is called on it
> clusterStartUp.getMember(1).invoke(() -> {
> RedisKey throwingKey = new
> RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
> ThrowingRedisString throwingRedisString = new ThrowingRedisString();
>
> throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
>
> ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
> throwingRedisString);
> });
> String newValue = "should_not_be_set";
> assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
> throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
>
> assertThat(jedis.get(key1)).isEqualTo(value1);
> assertThat(jedis.get(key2)).isEqualTo(value2);
>
> assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
> IgnoredException.removeAllExpectedExceptions();
> }
> static class ThrowingRedisString extends RedisString {
> @Override
> public void set(Region region, RedisKey key, byte[]
> newValue,
> SetOptions options) {
> throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
> }
> }{code}
> This test fails due to {{key1}} having its value set to {{newValue}} despite
> the fact that MSET is supposed to be atomic.
> Given the similar implementations each command uses, it is very likely that
> RENAME, MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10121) Transactional Redis commands are not actually transactional
Donal Evans created GEODE-10121:
---
Summary: Transactional Redis commands are not actually
transactional
Key: GEODE-10121
URL: https://issues.apache.org/jira/browse/GEODE-10121
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0, 1.16.0
Reporter: Donal Evans
The following test (if added to MSetDUnitTest) is intended to show that MSET is
transactional in nature by having the final key to be set throw an exception,
which should roll back the previous set values:
{code:java}
public static final String THROWING_REDIS_STRING_EXCEPTION = "to be ignored";
@Test
public void mset_isTransactional() {
IgnoredException.addIgnoredException(THROWING_REDIS_STRING_EXCEPTION);
String hashTag = "{" + clusterStartUp.getKeyOnServer("tag", 1) + "}";
String key1 = hashTag + "key1";
String value1 = "value1";
jedis.set(key1, value1);
String key2 = hashTag + "key2";
String value2 = "value2";
jedis.set(key2, value2);
String throwingRedisStringKey = hashTag + "ThrowingRedisString";
String throwingStringValue = "ThrowingRedisStringValue";
// Put a test version of RedisString directly into the region that throws
if the multi-argument set() is called on it
clusterStartUp.getMember(1).invoke(() -> {
RedisKey throwingKey = new
RedisKey(throwingRedisStringKey.getBytes(StandardCharsets.UTF_8));
ThrowingRedisString throwingRedisString = new ThrowingRedisString();
throwingRedisString.set(throwingStringValue.getBytes(StandardCharsets.UTF_8));
ClusterStartupRule.getCache().getRegion(DEFAULT_REDIS_REGION_NAME).put(throwingKey,
throwingRedisString);
});
String newValue = "should_not_be_set";
assertThatThrownBy(() -> jedis.mset(key1, newValue, key2, newValue,
throwingRedisStringKey, newValue)).hasMessage(SERVER_ERROR_MESSAGE);
assertThat(jedis.get(key1)).isEqualTo(value1);
assertThat(jedis.get(key2)).isEqualTo(value2);
assertThat(jedis.get(throwingRedisStringKey)).isEqualTo(throwingStringValue);
IgnoredException.removeAllExpectedExceptions();
}
static class ThrowingRedisString extends RedisString {
@Override
public void set(Region region, RedisKey key, byte[]
newValue,
SetOptions options) {
throw new RuntimeException(THROWING_REDIS_STRING_EXCEPTION);
}
}{code}
This test fails due to {{key1}} having its value set to {{newValue}} despite
the fact that MSET is supposed to be atomic.
Given the similar implementations each command uses, it is very likely that
RENAME, MSETNX and SMOVE also show the same behaviour.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Reopened] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans reopened GEODE-10010:
-
Reopening as the original fix caused Windows tests to fail
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10010) CI: InfoStatsIntegrationTest > opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
[
https://issues.apache.org/jira/browse/GEODE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10010.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> CI: InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> --
>
> Key: GEODE-10010
> URL: https://issues.apache.org/jira/browse/GEODE-10010
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Kristen
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> http://files.apachegeode-ci.info/builds/apache-support-1-15-main/1.15.0-build.0836/test-results/integrationTest/1643742213/
> {code:java}
> > Task :geode-for-redis:integrationTest
> InfoStatsIntegrationTest >
> opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring FAILED
> java.lang.AssertionError:
> Expecting actual:
> 13.0
> to be close to:
> 19.0
> by less than 4.0 but difference was 6.0.
> (a difference of exactly 4.0 being considered valid)
> at
> org.apache.geode.redis.internal.commands.executor.server.AbstractRedisInfoStatsIntegrationTest.opsPerformedOverLastSecond_ShouldUpdate_givenOperationsOccurring(AbstractRedisInfoStatsIntegrationTest.java:174)
> 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)
> ...{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10049) Redis tests should include the entire error response message rather than just the error type
[
https://issues.apache.org/jira/browse/GEODE-10049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans resolved GEODE-10049.
-
Fix Version/s: 1.16.0
Resolution: Fixed
> Redis tests should include the entire error response message rather than just
> the error type
>
>
> Key: GEODE-10049
> URL: https://issues.apache.org/jira/browse/GEODE-10049
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.16.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Currently many tests look for substrings of error messages, rather than the
> error message as a whole. This has in the past led to cases where the Geode
> for Redis Module's error messages have not precisely matched those of native
> Redis.
> For example, if the test is:
> {code:java}
> assertThatThrownBy(
> () -> jedis.hsetnx(string_key, field, "something else"))
> .isInstanceOf(JedisDataException.class)
> .hasMessageContaining("WRONGTYPE");{code}
> instead we should probably look for the full error message that native Redis
> puts out:
> {code:java}
> .hasMessage("WRONGTYPE Operation against a key holding the wrong kind of
> value"){code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10091) Benchmark instability in RedisZaddAndZremBenchmark
Donal Evans created GEODE-10091:
---
Summary: Benchmark instability in RedisZaddAndZremBenchmark
Key: GEODE-10091
URL: https://issues.apache.org/jira/browse/GEODE-10091
Project: Geode
Issue Type: Bug
Components: benchmarks, redis
Affects Versions: 1.15.0
Reporter: Donal Evans
{noformat}
This is ITERATION 1 of benchmarking against baseline.
RedisGetBenchmark avg ops/sec
Baseline:428358.55 Test:446241.49 Difference: +4.2%
avg latency
Baseline: 1678809.55 Test: 1611045.34 Difference: -4.0%
RedisHgetBenchmark avg ops/sec
Baseline:438535.25 Test:441078.97 Difference: +0.6%
avg latency
Baseline: 1638968.92 Test: 1630999.16 Difference: -0.5%
RedisHsetAndHgetBenchmark avg ops/sec
Baseline:191331.54 Test:186806.37 Difference: -2.4%
avg latency
Baseline: 3759694.09 Test: 3850396.04 Difference: +2.4%
RedisHsetBenchmark avg ops/sec
Baseline:308079.41 Test:303715.78 Difference: -1.4%
avg latency
Baseline: 2332102.91 Test: 2367639.93 Difference: +1.5%
RedisSetBenchmark avg ops/sec
Baseline:318147.74 Test:326996.22 Difference: +2.8%
avg latency
Baseline: 2263687.57 Test: 2198181.68 Difference: -2.9%
RedisWeightedHsetAndHgetBenchmark avg ops/sec
Baseline:390383.79 Test:385565.48 Difference: -1.2%
avg latency
Baseline: 1842561.96 Test: 1864716.09 Difference: +1.2%
RedisWeightedZaddAndZrangeBenchmark avg ops/sec
Baseline:375078.82 Test:350886.03 Difference: -6.5%
avg latency
Baseline: 1917476.15 Test: 2049452.87 Difference: +6.9%
RedisZaddAndZremBenchmark avg ops/sec
Baseline:124763.60 Test:118600.72 Difference: -4.9%
avg latency
Baseline: 5766048.34 Test: 6065491.13 Difference: +5.2%
RedisZaddBenchmark avg ops/sec
Baseline:432494.29 Test:438594.53 Difference: +1.4%
avg latency
Baseline: 1662639.09 Test: 1639906.18 Difference: -1.4%
RedisZrangeBenchmark avg ops/sec
Baseline:295523.77 Test:340381.87 Difference: +15.2%
avg latency
Baseline: 2433250.54 Test: 2112961.66 Difference: -13.2%
RedisZrangeByScoreBenchmark avg ops/sec
Baseline:285836.33 Test:356142.91 Difference: +24.6%
avg latency
Baseline: 2515708.23 Test: 2019249.68 Difference: -19.7%
This is ITERATION 2 of benchmarking against baseline.
RedisWeightedZaddAndZrangeBenchmark avg ops/sec
Baseline:358570.33 Test:348012.02 Difference: -2.9%
avg latency
Baseline: 2005804.05 Test: 2066535.24 Difference: +3.0%
RedisZaddAndZremBenchmark avg ops/sec
Baseline:122900.38 Test:115226.22 Difference: -6.2%
avg latency
Baseline: 5858357.13 Test: 6243018.38 Difference: +6.6%
This is ITERATION 3 of benchmarking against baseline.
RedisZaddAndZremBenchmark avg ops/sec
Baseline:125677.36 Test:118359.94 Difference: -5.8%
avg latency
Baseline: 5721859.26 Test: 6082944.28 Difference: +6.3%
This is ITERATION 4 of benchmarking against baseline.
RedisZaddAndZremBenchmark avg ops/sec
Baseline:122099.00 Test:115864.88 Difference: -5.1%
avg latency
Baseline: 5893264.03 Test: 6203439.89 Difference: +5.3%
This is ITERATION 5 of benchmarking against baseline.
RedisZaddAndZremBenchmark avg ops/sec
Baseline:122234.53 Test:116038.15 Difference: -5.1%
[jira] [Updated] (GEODE-10090) CI Failure: ClientServerTransactionCCEDUnitTest > testTransactionException fails during teardown due to nonzero hostedTransactionInProgress
[
https://issues.apache.org/jira/browse/GEODE-10090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10090:
Description:
{noformat}
> Task :geode-core:distributedTest
ClientServerTransactionCCEDUnitTest > testTransactionException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
running on Host
heavy-lifter-c158d9b1-495a-5f45-8dc4-ef1fd3a17ec3.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:171)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.preTearDown(JUnit4CacheTestCase.java:336)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] [Updated] (GEODE-10090) CI Failure: ClientServerTransactionCCEDUnitTest > testTransactionException fails during teardown due to nonzero hostedTransactionInProgress
[
https://issues.apache.org/jira/browse/GEODE-10090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-10090:
Description:
{noformat}
> Task :geode-core:distributedTest
ClientServerTransactionCCEDUnitTest > testTransactionException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
running on Host
heavy-lifter-c158d9b1-495a-5f45-8dc4-ef1fd3a17ec3.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:171)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.preTearDown(JUnit4CacheTestCase.java:336)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor.stop(JUnitPlatformTestClassProcessor.java:75)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.stop(SuiteTestClassProcessor.java:61)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
[jira] [Updated] (GEODE-9929) CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null TransactionStateProxy on accessor server
[
https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9929:
---
Description:
There are two distinct failures in the attached artifacts for this ticket. The
first is the one below, which is the one triaged by Hale
{noformat}
org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
testTXCreationAndCleanupAtCommit FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertNotNull(Assert.java:713)
at org.junit.Assert.assertNotNull(Assert.java:723)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
{noformat}
The second failure is this one, which is due to a nonzero value returned by
{{hostedTransactionInProgressForTest()}} in the test teardown. A new ticket,
GEODE-10090, has been filed to track this second failure.
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
running on Host 9acb6806d25d with 4 VMs at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631) at
org.apache.geode.test.dunit.VM.invoke(VM.java:473) at
org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121) at
org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109) at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
Caused by:
java.lang.AssertionError: Event never occurred after 3 ms:
at org.junit.Assert.fail(Assert.java:89)
at org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
8838 tests completed, 1 failed, 458 skipped{noformat}
was:
{noformat}
org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
testTXCreationAndCleanupAtCommit FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertNotNull(Assert.java:713)
at org.junit.Assert.assertNotNull(Assert.java:723)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
Caused by:
java.lang.AssertionError: Event never occurred after 3 ms:
at org.junit.Assert.fail(Assert.java:89)
at org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
8838 tests completed, 1 failed, 458 skipped
{noformat}
> CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails
> due to null TransactionStateProxy on accessor server
>
[jira] [Created] (GEODE-10090) CI Failure: ClientServerTransactionCCEDUnitTest > testTransactionException fails during teardown due to nonzero hostedTransactionInProgress
Donal Evans created GEODE-10090:
---
Summary: CI Failure: ClientServerTransactionCCEDUnitTest >
testTransactionException fails during teardown due to nonzero
hostedTransactionInProgress
Key: GEODE-10090
URL: https://issues.apache.org/jira/browse/GEODE-10090
Project: Geode
Issue Type: Bug
Components: tests, transactions
Affects Versions: 1.15.0
Reporter: Donal Evans
{noformat}
> Task :geode-core:distributedTest
ClientServerTransactionCCEDUnitTest > testTransactionException FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
running on Host
heavy-lifter-c158d9b1-495a-5f45-8dc4-ef1fd3a17ec3.c.apachegeode-ci.internal
with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:171)
at
org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.preTearDown(JUnit4CacheTestCase.java:336)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480)
at sun.reflect.GeneratedMethodAccessor8.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
at
org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at
org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at
org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at
org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:108)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at
org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:96)
at
org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:75)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.processAllTestClasses(JUnitPlatformTestClassProcessor.java:99)
at
org.gradle.api.internal.tasks.testing.junitplatform.JUnitPlatformTestClassProcessor$CollectAllTestClassesExecutor.access$000(JUnitPlatformTestClassProcessor.java:79)
at
[jira] [Updated] (GEODE-9929) CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null TransactionStateProxy on accessor server
[
https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9929:
---
Summary: CI Failure:
RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null
TransactionStateProxy on accessor server (was: CI Failure:
RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null
TransactionManager on accessor server)
> CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails
> due to null TransactionStateProxy on accessor server
> --
>
> Key: GEODE-9929
> URL: https://issues.apache.org/jira/browse/GEODE-9929
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: Kristen
>Priority: Major
>
>
> {noformat}
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
> testTXCreationAndCleanupAtCommit FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertNotNull(Assert.java:713)
> at org.junit.Assert.assertNotNull(Assert.java:723)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
> 8838 tests completed, 1 failed, 458 skipped
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9929) CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null TransactionManager on accessor server
[
https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9929:
---
Summary: CI Failure:
RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails due to null
TransactionManager on accessor server (was: CI Failure:
RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit )
> CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit fails
> due to null TransactionManager on accessor server
> ---
>
> Key: GEODE-9929
> URL: https://issues.apache.org/jira/browse/GEODE-9929
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: Kristen
>Priority: Major
>
>
> {noformat}
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
> testTXCreationAndCleanupAtCommit FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertNotNull(Assert.java:713)
> at org.junit.Assert.assertNotNull(Assert.java:723)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
> 8838 tests completed, 1 failed, 458 skipped
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9929) CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit
[
https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9929:
---
Summary: CI Failure:
RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit (was:
testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest)
> CI Failure: RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit
>
>
> Key: GEODE-9929
> URL: https://issues.apache.org/jira/browse/GEODE-9929
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: Kristen
>Priority: Major
>
>
> {noformat}
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
> testTXCreationAndCleanupAtCommit FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:87)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertNotNull(Assert.java:713)
> at org.junit.Assert.assertNotNull(Assert.java:723)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
> running on Host 9acb6806d25d with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
> at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
> at
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
> 8838 tests completed, 1 failed, 458 skipped
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9929) testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-9929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9929:
---
Description:
{noformat}
org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
testTXCreationAndCleanupAtCommit FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertNotNull(Assert.java:713)
at org.junit.Assert.assertNotNull(Assert.java:723)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
Caused by:
java.lang.AssertionError: Event never occurred after 3 ms:
at org.junit.Assert.fail(Assert.java:89)
at org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
8838 tests completed, 1 failed, 458 skipped
{noformat}
was:
org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
testTXCreationAndCleanupAtCommit FAILED
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call in VM 0
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.doBasicChecks(RemoteTransactionDUnitTest.java:590)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.testTXCreationAndCleanupAtCommit(RemoteTransactionDUnitTest.java:565)
Caused by:
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:87)
at org.junit.Assert.assertTrue(Assert.java:42)
at org.junit.Assert.assertNotNull(Assert.java:713)
at org.junit.Assert.assertNotNull(Assert.java:723)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$8.call(RemoteTransactionDUnitTest.java:595)
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 1
running on Host 9acb6806d25d with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
at org.apache.geode.test.dunit.VM.invoke(VM.java:473)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:121)
at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:109)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest.preTearDownCacheTestCase(RemoteTransactionDUnitTest.java:182)
Caused by:
java.lang.AssertionError: Event never occurred after 3 ms:
at org.junit.Assert.fail(Assert.java:89)
at org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:144)
at
org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call(RemoteTransactionDUnitTest.java:149)
8838 tests completed, 1 failed, 458 skipped
> testTXCreationAndCleanupAtCommit when running RemoteTransactionDUnitTest
>
>
> Key: GEODE-9929
> URL: https://issues.apache.org/jira/browse/GEODE-9929
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: Kristen
>Priority: Major
>
>
> {noformat}
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest >
> testTXCreationAndCleanupAtCommit FAILED
> org.apache.geode.test.dunit.RMIException:
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest fails due to PoolImpl.getRedundantNames() not returning expected servers
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9785:
---
Description:
{noformat}
org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
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.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
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.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
[jira] [Updated] (GEODE-9785) CI Failure: RedundancyLevelPart2DUnitTest fails due to PoolImpl.getRedundantNames() not returning expected servers
[
https://issues.apache.org/jira/browse/GEODE-9785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Donal Evans updated GEODE-9785:
---
Summary: CI Failure: RedundancyLevelPart2DUnitTest fails due to
PoolImpl.getRedundantNames() not returning expected servers (was: CI Failure:
RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails FAILED)
> CI Failure: RedundancyLevelPart2DUnitTest fails due to
> PoolImpl.getRedundantNames() not returning expected servers
> --
>
> Key: GEODE-9785
> URL: https://issues.apache.org/jira/browse/GEODE-9785
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Eric Shu
>Priority: Major
> Labels: needsTriage
>
> {noformat}
> org.junit.ComparisonFailure: expected:<[2]> but was:<[0]>
> 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.RedundancyLevelPart2DUnitTest.testRedundancySpecifiedEPFails(RedundancyLevelPart2DUnitTest.java:215)
> 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.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
>
