[jira] [Created] (GEODE-9196) CI: NativeRedisClusterTest.classMethod failed
Xiaojian Zhou created GEODE-9196: Summary: CI: NativeRedisClusterTest.classMethod failed Key: GEODE-9196 URL: https://issues.apache.org/jira/browse/GEODE-9196 Project: Geode Issue Type: Bug Components: redis Reporter: Xiaojian Zhou org.apache.geode.redis.NativeRedisClusterTest > classMethod FAILED org.junit.ComparisonFailure: [Incorrect primary node count] expected:<[3]> 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.test.dunit.rules.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:90) at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182) at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164) at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56) at java.lang.Thread.run(Thread.java:748) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9191) PR clear should not miss clearing bucket which lost primary
Xiaojian Zhou created GEODE-9191: Summary: PR clear should not miss clearing bucket which lost primary Key: GEODE-9191 URL: https://issues.apache.org/jira/browse/GEODE-9191 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou This scenario is found when introducing GII test case for PR clear. The sequence is: (1) there're 3 servers, server1 is accessor, server2 and server3 are datastores. (2) shutdown server2 (3) send PR clear from server1 (accessor) and restart server2 at the same time. There's a race that server2 did not receive the PartitionedRegionClearMessage. (4) server2 finished GII (5) only server3 received PartitionedRegionClearMessage and it hosts all the primary buckets. When PR clear thread iterates through these primary buckets one by one, some of them might lose primary to server2. (6) BR.cmnClearRegion will return immediately since it's no longer primary, but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be called. So from the caller point of view, this bucket is cleared. It wouldn't even throw PartitionedRegionPartialClearException. The problem is: before calling cmnClearRegion, we should call BR.doLockForPrimary to make sure it's still primary. If not, throw exception. Then clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for this bucket. The expected behavior in this scenario is to throw PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9191) PR clear should not miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9191: - Parent: GEODE-7665 Issue Type: Sub-task (was: Bug) > PR clear should not miss clearing bucket which lost primary > --- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Priority: Major > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the caller point of view, this bucket is cleared. It wouldn't > even throw PartitionedRegionPartialClearException. > The problem is: > before calling cmnClearRegion, we should call BR.doLockForPrimary to make > sure it's still primary. If not, throw exception. Then > clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for > this bucket. > The expected behavior in this scenario is to throw > PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9191) PR clear should not miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9191: - Labels: GeodeOperationAPI (was: ) > PR clear should not miss clearing bucket which lost primary > --- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the caller point of view, this bucket is cleared. It wouldn't > even throw PartitionedRegionPartialClearException. > The problem is: > before calling cmnClearRegion, we should call BR.doLockForPrimary to make > sure it's still primary. If not, throw exception. Then > clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for > this bucket. > The expected behavior in this scenario is to throw > PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9191) PR clear should not miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9191: Assignee: Xiaojian Zhou > PR clear should not miss clearing bucket which lost primary > --- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the caller point of view, this bucket is cleared. It wouldn't > even throw PartitionedRegionPartialClearException. > The problem is: > before calling cmnClearRegion, we should call BR.doLockForPrimary to make > sure it's still primary. If not, throw exception. Then > clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for > this bucket. > The expected behavior in this scenario is to throw > PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9191) PR clear could miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9191: - Summary: PR clear could miss clearing bucket which lost primary (was: PR clear should not miss clearing bucket which lost primary) > PR clear could miss clearing bucket which lost primary > -- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the caller point of view, this bucket is cleared. It wouldn't > even throw PartitionedRegionPartialClearException. > The problem is: > before calling cmnClearRegion, we should call BR.doLockForPrimary to make > sure it's still primary. If not, throw exception. Then > clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for > this bucket. > The expected behavior in this scenario is to throw > PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7671) Partitioned Region clear operations can occur successfully during GII
[ https://issues.apache.org/jira/browse/GEODE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17331601#comment-17331601 ] Xiaojian Zhou commented on GEODE-7671: -- When adding the dunit tests for GII and PR clear, I found some bugs. So these dunit tests will be used to verify the fix and commit together in GEODE-9191. > Partitioned Region clear operations can occur successfully during GII > -- > > Key: GEODE-7671 > URL: https://issues.apache.org/jira/browse/GEODE-7671 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successful when the region is undergoing GII > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region when they are undergoing GII from another member > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7671) Partitioned Region clear operations can occur successfully during GII
[ https://issues.apache.org/jira/browse/GEODE-7671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-7671: Assignee: Xiaojian Zhou (was: Benjamin P Ross) > Partitioned Region clear operations can occur successfully during GII > -- > > Key: GEODE-7671 > URL: https://issues.apache.org/jira/browse/GEODE-7671 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successful when the region is undergoing GII > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region when they are undergoing GII from another member > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9191) PR clear could miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339313#comment-17339313 ] Xiaojian Zhou commented on GEODE-9191: -- More investigation found that the primary buckets could switch at any time especially when they are not balanced (usually happened in GII). We need to lock the primary from moving. The revised design will be: (1) coordinator(a server) assignAllBuckets. Then waits for all the primaries to show up. (2) coordinator sends lock message to all members. (3) upon received the lock message, each datastore server lockBucketCreationForRegionClear() then save current primary bucket number. (4) At each datastore, iterate through local primary bucket list to lock primary from moving and lock rvv. If either total locked primary buckets or total locked rvv buckets at this member is different with previous saved primary bucket number, unlock all of them and return RetryException to coordinator. (5) If coordinator received retry exception it will resend lock message and retry forever until succeeded. (6) After locked all the members' primary buckets, coordinator sends clear message to all the members. (6) each member clear primary buckets one by one and return number of buckets cleared. (7) Coordinator collect all the numbers cleared, if less than expected bucket number, throw PartialClearException to caller. This could happen when a member is offline in the middle of clear. (8) If any member exit in the middle of clear, since we will not allow to create bucket during clear, so unlock all the locks and return number of buckets cleared to coordinator. The coordinator will finally throw PartialClearException. (9) if the coordinator exit in the middle of clear, unlock all the locks and throw PartialClearException. > PR clear could miss clearing bucket which lost primary > -- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the caller point of view, this bucket is cleared. It wouldn't > even throw PartitionedRegionPartialClearException. > The problem is: > before calling cmnClearRegion, we should call BR.doLockForPrimary to make > sure it's still primary. If not, throw exception. Then > clearedBuckets.add(localPrimaryBucketRegion.getId()); will not be called for > this bucket. > The expected behavior in this scenario is to throw > PartitionedRegionPartialClearException. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9191) PR clear could miss clearing bucket which lost primary
[ https://issues.apache.org/jira/browse/GEODE-9191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17339313#comment-17339313 ] Xiaojian Zhou edited comment on GEODE-9191 at 5/4/21, 10:28 PM: More investigation found that the primary buckets could switch at any time especially when they are not balanced (usually happened in GII). We need to lock the primary from moving. The revised design will be: (1) coordinator(a server) assignAllBuckets. Then waits for all the primaries to show up. (2) coordinator sends lock message to all members. (3) upon received the lock message, each datastore server saves current primary bucket number for future reference. (4) At each datastore, iterate through local primary bucket list to lock primary from moving and lock rvv. If either total locked primary buckets or total locked rvv buckets at this member is different with previous saved primary bucket number, unlock all of them and return RetryException to coordinator. (5) If coordinator received retry exception it will resend lock message and retry forever until succeeded. (6) After locked all the members' primary buckets, coordinator sends clear message to all the members. (6) each member clear primary buckets one by one and return number of buckets cleared. (7) Coordinator collect all the numbers cleared, if less than expected bucket number, throw PartialClearException to caller. This could happen when a member is offline in the middle of clear. (8) If any member exit in the middle of clear, the membership listener at coordinator will be notified. It will unlock all the locks and retry from locking then clearing. In retry, if the missing member's buckets are recreated in other member, the retry succeed. Otherwise, the total cleared buckets number is still lower than expected (i.e. PartitionOffline happened), throw the PartialClearException. (9) if the coordinator exit in the middle of clear, unlock all the locks and throw PartialClearException. was (Author: zhouxj): More investigation found that the primary buckets could switch at any time especially when they are not balanced (usually happened in GII). We need to lock the primary from moving. The revised design will be: (1) coordinator(a server) assignAllBuckets. Then waits for all the primaries to show up. (2) coordinator sends lock message to all members. (3) upon received the lock message, each datastore server lockBucketCreationForRegionClear() then save current primary bucket number. (4) At each datastore, iterate through local primary bucket list to lock primary from moving and lock rvv. If either total locked primary buckets or total locked rvv buckets at this member is different with previous saved primary bucket number, unlock all of them and return RetryException to coordinator. (5) If coordinator received retry exception it will resend lock message and retry forever until succeeded. (6) After locked all the members' primary buckets, coordinator sends clear message to all the members. (6) each member clear primary buckets one by one and return number of buckets cleared. (7) Coordinator collect all the numbers cleared, if less than expected bucket number, throw PartialClearException to caller. This could happen when a member is offline in the middle of clear. (8) If any member exit in the middle of clear, since we will not allow to create bucket during clear, so unlock all the locks and return number of buckets cleared to coordinator. The coordinator will finally throw PartialClearException. (9) if the coordinator exit in the middle of clear, unlock all the locks and throw PartialClearException. > PR clear could miss clearing bucket which lost primary > -- > > Key: GEODE-9191 > URL: https://issues.apache.org/jira/browse/GEODE-9191 > Project: Geode > Issue Type: Sub-task >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > This scenario is found when introducing GII test case for PR clear. The > sequence is: > (1) there're 3 servers, server1 is accessor, server2 and server3 are > datastores. > (2) shutdown server2 > (3) send PR clear from server1 (accessor) and restart server2 at the same > time. There's a race that server2 did not receive the > PartitionedRegionClearMessage. > (4) server2 finished GII > (5) only server3 received PartitionedRegionClearMessage and it hosts all the > primary buckets. When PR clear thread iterates through these primary buckets > one by one, some of them might lose primary to server2. > (6) BR.cmnClearRegion will return immediately since it's no longer primary, > but clearedBuckets.add(localPrimaryBucketRegion.getId()); will still be > called. So from the
[jira] [Comment Edited] (GEODE-8928) Need to revert GEODE-8768 for a better fix
[ https://issues.apache.org/jira/browse/GEODE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281457#comment-17281457 ] Xiaojian Zhou edited comment on GEODE-8928 at 2/9/21, 12:42 AM: Original fix caused "Locator rs-FullRegression06170449a7i3large-hydra-client-26[26649] not found in distributed system 1" failure. equals() is paying attention to the new field, but if one identifier doesn't have a value there it will hash to a different place than one that does. Equals for these two IDs would return true but the collection will never make that comparison. The class is therefor broken and the PR needs to be reverted. was (Author: zhouxj): Original fix caused "Locator rs-FullRegression06170449a7i3large-hydra-client-26[26649] not found in distributed system 1" failure. > Need to revert GEODE-8768 for a better fix > -- > > Key: GEODE-8928 > URL: https://issues.apache.org/jira/browse/GEODE-8928 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8928) Need to revert GEODE-8768 for a better fix
Xiaojian Zhou created GEODE-8928: Summary: Need to revert GEODE-8768 for a better fix Key: GEODE-8928 URL: https://issues.apache.org/jira/browse/GEODE-8928 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8928) Need to revert GEODE-8768 for a better fix
[ https://issues.apache.org/jira/browse/GEODE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281457#comment-17281457 ] Xiaojian Zhou commented on GEODE-8928: -- It caused "Locator rs-FullRegression06170449a7i3large-hydra-client-26[26649] not found in distributed system 1" failure. > Need to revert GEODE-8768 for a better fix > -- > > Key: GEODE-8928 > URL: https://issues.apache.org/jira/browse/GEODE-8928 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8928) Need to revert GEODE-8768 for a better fix
[ https://issues.apache.org/jira/browse/GEODE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17281457#comment-17281457 ] Xiaojian Zhou edited comment on GEODE-8928 at 2/8/21, 11:56 PM: Original fix caused "Locator rs-FullRegression06170449a7i3large-hydra-client-26[26649] not found in distributed system 1" failure. was (Author: zhouxj): It caused "Locator rs-FullRegression06170449a7i3large-hydra-client-26[26649] not found in distributed system 1" failure. > Need to revert GEODE-8768 for a better fix > -- > > Key: GEODE-8928 > URL: https://issues.apache.org/jira/browse/GEODE-8928 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9060: Assignee: Xiaojian Zhou > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
Xiaojian Zhou created GEODE-9060: Summary: checkMyStateOnMemebers is better not to change the replicates Key: GEODE-9060 URL: https://issues.apache.org/jira/browse/GEODE-9060 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou This is an enhancement to previous GEODE-9003. The previous fix will remove the members in replicates if it cannot recognize current member, thus these removed members will not acting as GII provider candidates. The fix is correct. However, Dan suggested to keep the replicates as is to be more conservative. These members will still act as GII provider candidates even they cannot recognize current member due to the split-brain. Conceptually these members should be the same as other online members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9060: - Labels: GeodeOperationAPI (was: ) > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9060. -- Fix Version/s: 1.15.0 Resolution: Fixed > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9003) Remove the member from replicates as GII candidate if it's not part of the same distributed system
[ https://issues.apache.org/jira/browse/GEODE-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17312738#comment-17312738 ] Xiaojian Zhou commented on GEODE-9003: -- It will be fixed in GEODE-9060 instead. > Remove the member from replicates as GII candidate if it's not part of the > same distributed system > -- > > Key: GEODE-9003 > URL: https://issues.apache.org/jira/browse/GEODE-9003 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9003) Remove the member from replicates as GII candidate if it's not part of the same distributed system
[ https://issues.apache.org/jira/browse/GEODE-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9003. -- Fix Version/s: 1.15.0 Assignee: Xiaojian Zhou Resolution: Fixed > Remove the member from replicates as GII candidate if it's not part of the > same distributed system > -- > > Key: GEODE-9003 > URL: https://issues.apache.org/jira/browse/GEODE-9003 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9003) Remove the member from replicates as GII candidate if it's not part of the same distributed system
Xiaojian Zhou created GEODE-9003: Summary: Remove the member from replicates as GII candidate if it's not part of the same distributed system Key: GEODE-9003 URL: https://issues.apache.org/jira/browse/GEODE-9003 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9014) geode document should add example for lucene nest object insert and query
Xiaojian Zhou created GEODE-9014: Summary: geode document should add example for lucene nest object insert and query Key: GEODE-9014 URL: https://issues.apache.org/jira/browse/GEODE-9014 Project: Geode Issue Type: Bug Components: docs Reporter: Xiaojian Zhou The detail example is described in GEODE-9013. This use case should be added into document. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9013) geode example for lucene should add use case for nest object
Xiaojian Zhou created GEODE-9013:
Summary: geode example for lucene should add use case for nest
object
Key: GEODE-9013
URL: https://issues.apache.org/jira/browse/GEODE-9013
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
We need to add example to guide users to use gfsh to insert nest object with
array, then query on the array's item.
Here are the use case:
define following user object classes:
package examples;
import java.io.Serializable;
public class ExampleRegion implements Serializable {
private ExampleIdentifier exampleIdentifier;
public ExampleRegion() {}
public ExampleRegion(ExampleIdentifier exampleIdentifier) {
this.exampleIdentifier = exampleIdentifier;
}
public void setExampleIdentifier(ExampleIdentifier exampleIdentifier) {
this.exampleIdentifier = exampleIdentifier;
}
public ExampleIdentifier getExampleIdentifier() {
return this.exampleIdentifier;
}
}
package examples;
import java.io.Serializable;
public class ExampleIdentifier implements Serializable {
private String exampleId;
private SystemId[] systemIds;
public ExampleIdentifier() {}
public ExampleIdentifier(String exampleId, SystemId[] systemIds) {
this.exampleId = exampleId;
this.systemIds = systemIds;
}
public void setExampleId(String exampleId) {
this.exampleId = exampleId;
}
public void setSystemIds(SystemId[] systemIds) {
this.systemIds = systemIds;
}
public String getExampleId() {
return this.exampleId;
}
public SystemId[] getSystemIds() {
return this.systemIds;
}
}
package examples;
import java.io.Serializable;
public class SystemId implements Serializable {
private String id;
private String system;
public SystemId() {}
SystemId(String id, String system) {
this.id = id;
this.system = system;
}
public void setId(String id) {
this.id = id;
}
public void setSystem(String system) {
this.system = system;
}
public String getId() {
return this.id;
}
public String getSystem() {
return this.system;
}
}
Then use gfsh to do insert and query:
gfsh>deploy
--jar=/Users/gzhou/git3/lucene_example/build/libs/lucene_example-0.0.1.jar
gfsh>create lucene index --name=arrayIndex --region=/exampleRegion
--field=exampleIdentifier.systemIds.system --analyzer=DEFAULT
--serializer=org.apache.geode.cache.lucene.FlatFormatSerializer
gfsh>create region --name=exampleRegion --type=PARTITION
gfsh>put --region=/exampleRegion --key="('id':'1')"
--value="('exampleIdentifier': {'exampleId': '0','systemIds':[{'id':
'ID','system': 'MUREX'}]})" --value-class="examples.ExampleRegion"
gfsh>put --region=/exampleRegion --key="('id':'1')"
--value="('exampleIdentifier': {'exampleId': '0','systemIds':[{'id':
'Id','system': 'MUREX'}]})" --value-class="examples.ExampleRegion"
gfsh>put --region=/exampleRegion --key="('id':'2')"
--value="('exampleIdentifier': {'exampleId': '1','systemIds':[{'id':
'ID','system': 'MUREX'}, {'id': 'ID1','system': 'WHITEBOX'}]})"
--value-class="examples.ExampleRegion"
gfsh>search lucene --name=arrayIndex --region=/exampleRegion
--queryString="exampleIdentifier.systemIds.system:MUREX"
--defaultField="exampleIdentifier.systemIds.system"
key | value | score
-- | --- | --
{'id':'1'} | examples.ExampleRegion@105ea825 | 0.2876821
{'id':'2'} | examples.ExampleRegion@4a0c4c91 | 0.25811607
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9015) Lucene query on nest object's array item hit NPE
Xiaojian Zhou created GEODE-9015:
Summary: Lucene query on nest object's array item hit NPE
Key: GEODE-9015
URL: https://issues.apache.org/jira/browse/GEODE-9015
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
create lucene index --name=arrayIndex --region=/exampleRegion
--field=exampleIdentifier.systemIds[0].system --analyzer=DEFAULT
--serializer=org.apache.geode.cache.lucene.FlatFormatSerializer
create region --name=exampleRegion --type=PARTITION
put --region=/exampleRegion --key="('id':'1')" --value="('exampleIdentifier':
{'exampleId': '0','systemIds':[{'id': 'ID','system': 'MUREX'}]})"
put --region=/exampleRegion --key="('id':'2')" --value="('exampleIdentifier':
{'exampleId': '1','systemIds':[{'id': 'ID','system': 'MUREX'}, {'id':
'ID1','system': 'WHITEBOX'}]})"
search lucene --name=arrayIndex --region=/exampleRegion
--queryString="exampleIdentifier.systemIds[0].system:MUREX"
--defaultField="exampleIdentifier.systemIds[0].system"
gfsh>search lucene --name=arrayIndex --region=/exampleRegion
--queryString="exampleIdentifier.systemIds[0].system:MUREX"
--defaultField="exampleIdentifier.systemIds[0].system"
Error while processing command Reason : class
java.lang.NullPointerException cannot be cast to class java.util.Set
(java.lang.NullPointerException and java.util.Set are in module java.base of
loader 'bootstrap')
This is due to user used wrong syntax in creating index and query.
It is not supposed to use array item as field name. We should use array's name
here.
The correct syntax is:
gfsh>create lucene index --name=arrayIndex --region=/exampleRegion
--field=exampleIdentifier.systemIds.system --analyzer=DEFAULT
--serializer=org.apache.geode.cache.lucene.FlatFormatSerializer
gfsh>search lucene --name=arrayIndex --region=/exampleRegion
--queryString="exampleIdentifier.systemIds.system:MUREX"
--defaultField="exampleIdentifier.systemIds.system"
However, our code should report better error message instead of throwing NPE.
see GEODE-9013 for detail use case example.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9133) refactor current notifyGatewaySender to support regionEvent
Xiaojian Zhou created GEODE-9133: Summary: refactor current notifyGatewaySender to support regionEvent Key: GEODE-9133 URL: https://issues.apache.org/jira/browse/GEODE-9133 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou Current notifyGatewaySender hard-coded to use EntryEventImpl. There's a requirement to notify gateway senders or AEQs with regionEvent, such as clear region event. To support that, we have to refactor the related classes to use InternalCacheEvent interface instead of using EntryEventImpl. With that refactoring, we can send a clear region event to an AEQ, to lucene index, or even to remote site via WAN. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9133) refactor current notifyGatewaySender to support regionEvent
[ https://issues.apache.org/jira/browse/GEODE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9133: - Labels: GeodeOperationAPI (was: ) > refactor current notifyGatewaySender to support regionEvent > --- > > Key: GEODE-9133 > URL: https://issues.apache.org/jira/browse/GEODE-9133 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > Current notifyGatewaySender hard-coded to use EntryEventImpl. There's a > requirement to notify gateway senders or AEQs with regionEvent, such as clear > region event. > To support that, we have to refactor the related classes to use > InternalCacheEvent interface instead of using EntryEventImpl. > With that refactoring, we can send a clear region event to an AEQ, to lucene > index, or even to remote site via WAN. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9133) refactor current notifyGatewaySender to support regionEvent
[ https://issues.apache.org/jira/browse/GEODE-9133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9133: Assignee: Xiaojian Zhou > refactor current notifyGatewaySender to support regionEvent > --- > > Key: GEODE-9133 > URL: https://issues.apache.org/jira/browse/GEODE-9133 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > Current notifyGatewaySender hard-coded to use EntryEventImpl. There's a > requirement to notify gateway senders or AEQs with regionEvent, such as clear > region event. > To support that, we have to refactor the related classes to use > InternalCacheEvent interface instead of using EntryEventImpl. > With that refactoring, we can send a clear region event to an AEQ, to lucene > index, or even to remote site via WAN. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7674) Partitioned region clear should handle/update lucene index
[ https://issues.apache.org/jira/browse/GEODE-7674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-7674. -- Fix Version/s: 1.15.0 Resolution: Fixed > Partitioned region clear should handle/update lucene index > -- > > Key: GEODE-7674 > URL: https://issues.apache.org/jira/browse/GEODE-7674 > Project: Geode > Issue Type: Sub-task > Components: lucene, regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons, pull-request-available > Fix For: 1.15.0 > > > Clear operation on partitioned region should appropriately handle lucene > indexes defined on that partitioned region. > Existing behavior (complexities in updating lucene indexes): > The lucene indexes are managed through AsyncEventQueue (AEQ); the region > operations on the clear (both for replicated and partitioned region) > generated RegionEvents, currently the AEQ does not support handling > RegionEvent. Supporting RegionEvent with AEQ is separate task which needs to > be considered outside of the clear implementation. > Till the RegionEvents are supported on AEQs, the PR clear will not be > supported on regions with Lucene indexes. > Expectation: > Throw exception for PR clear operation when there is lucene index on the > region. > Acceptance : > - Add test to verify exception is thrown when PR clear is performed on the > region with local clear. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8928) Need to revert GEODE-8768 for a better fix
[ https://issues.apache.org/jira/browse/GEODE-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8928. -- Resolution: Won't Fix It has been reverted by original author. No need to use this ticket to revert. > Need to revert GEODE-8768 for a better fix > -- > > Key: GEODE-8928 > URL: https://issues.apache.org/jira/browse/GEODE-8928 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9522: - Summary: When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection. (was: Operations to replicate region were notified registered client in misorder due to switching primary queue ) > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9543) CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED
[ https://issues.apache.org/jira/browse/GEODE-9543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9543. -- Resolution: Duplicate duplicated with GEODE-9541 > CI: > org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > FAILED > - > > Key: GEODE-9543 > URL: https://issues.apache.org/jira/browse/GEODE-9543 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Xiaojian Zhou >Priority: Major > > It's found in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140 > org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > > numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED > org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at > org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) >
[jira] [Created] (GEODE-9543) CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED
Xiaojian Zhou created GEODE-9543: Summary: CI: org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest FAILED Key: GEODE-9543 URL: https://issues.apache.org/jira/browse/GEODE-9543 Project: Geode Issue Type: Bug Components: redis Reporter: Xiaojian Zhou It's found in https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/140 org.apache.geode.redis.internal.executor.pubsub.SubCommandsIntegrationTest > numpat_shouldNotIncludeChannelSubscriptions_forSameClient FAILED org.junit.ComparisonFailure: expected:<[1]L> but was:<[2]L> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at org.apache.geode.redis.internal.executor.pubsub.AbstractSubCommandsIntegrationTest.numpat_shouldNotIncludeChannelSubscriptions_forSameClient(AbstractSubCommandsIntegrationTest.java:334) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38) at org.junit.rules.RunRules.evaluate(RunRules.java:20) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33) at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94) at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119) at
[jira] [Created] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
Xiaojian Zhou created GEODE-9548: Summary: CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED Key: GEODE-9548 URL: https://issues.apache.org/jira/browse/GEODE-9548 Project: Geode Issue Type: Bug Components: lucene Reporter: Xiaojian Zhou org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED java.lang.AssertionError: Suspicious strings were written to the log during this run. Fix the strings or use IgnoredException.addIgnoredException to ignore. --- Found suspect string in 'dunit_suspect-locator.log' at line 435 [fatal 2021/08/24 20:16:46.325 UTC tid=70] Exception in processing request from 10.0.0.169 java.lang.Exception: Improperly configured client detected - use addPoolLocator to configure its locators instead of addPoolServer. at org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) at org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) at org.junit.Assert.fail(Assert.java:89) at org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) at org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) at org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) at junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) at junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) at org.junit.runners.ParentRunner.run(ParentRunner.java:413) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at
[jira] [Assigned] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9548: Assignee: Xiaojian Zhou > CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > - > > Key: GEODE-9548 > URL: https://issues.apache.org/jira/browse/GEODE-9548 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-locator.log' at line 435 > [fatal 2021/08/24 20:16:46.325 UTC tid=70] > Exception in processing request from 10.0.0.169 > java.lang.Exception: Improperly configured client detected - use > addPoolLocator to configure its locators instead of addPoolServer. > at > org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) > at > junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) > at > junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at >
[jira] [Updated] (GEODE-9548) CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] FAILED
[ https://issues.apache.org/jira/browse/GEODE-9548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9548: - Labels: GeodeOperationAPI (was: ) > CI: org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > - > > Key: GEODE-9548 > URL: https://issues.apache.org/jira/browse/GEODE-9548 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > org.apache.geode.cache.lucene.LuceneQueriesReindexDUnitTest > > afterReindexingWeShouldBeAbleToGetTheStatusOfIndexingProgress(PARTITION) [0] > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-locator.log' at line 435 > [fatal 2021/08/24 20:16:46.325 UTC tid=70] > Exception in processing request from 10.0.0.169 > java.lang.Exception: Improperly configured client detected - use > addPoolLocator to configure its locators instead of addPoolServer. > at > org.apache.geode.distributed.internal.ProtocolCheckerImpl.checkProtocol(ProtocolCheckerImpl.java:31) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:342) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:829) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:409) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:425) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:550) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:497) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:480) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > junitparams.internal.ParameterisedTestMethodRunner.runMethodInvoker(ParameterisedTestMethodRunner.java:47) > at > junitparams.internal.ParameterisedTestMethodRunner.runTestMethod(ParameterisedTestMethodRunner.java:40) > at > junitparams.internal.ParameterisedTestClassRunner.runParameterisedTest(ParameterisedTestClassRunner.java:146) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:446) > at junitparams.JUnitParamsRunner.runChild(JUnitParamsRunner.java:393) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329) > at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at org.junit.runners.ParentRunner.run(ParentRunner.java:413) > at >
[jira] [Commented] (GEODE-9320) CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
[
https://issues.apache.org/jira/browse/GEODE-9320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17404188#comment-17404188
]
Xiaojian Zhou commented on GEODE-9320:
--
See in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/145
> CI Failure: SetNXNativeRedisAcceptanceTest > classMethod FAILED
> ---
>
> Key: GEODE-9320
> URL: https://issues.apache.org/jira/browse/GEODE-9320
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Jens Deppe
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> org.apache.geode.redis.internal.executor.string.SetNXNativeRedisAcceptanceTest
> > classMethod FAILED
> 13:40:47org.testcontainers.containers.ContainerLaunchException: Container
> startup failed
> 13:40:47at
> org.testcontainers.containers.GenericContainer.doStart(GenericContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.GenericContainer.start(GenericContainer.java:311)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.startAmbassadorContainers(DockerComposeContainer.java:330)
> 13:40:47at
> org.testcontainers.containers.DockerComposeContainer.start(DockerComposeContainer.java:178)
> 13:40:47at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:85)
> 13:40:47at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 13:40:47at
> org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> 13:40:47at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
> 13:40:47at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
> 13:40:47at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> 13:40:47at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 13:40:47at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 13:40:47at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 13:40:47at java.lang.reflect.Method.invoke(Method.java:566)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
> 13:40:47at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
> 13:40:47at
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
> 13:40:47at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
> 13:40:47at
>
[jira] [Created] (GEODE-9522) Operations to replicate region were notified registered client in misorder due to switching primary queue
Xiaojian Zhou created GEODE-9522: Summary: Operations to replicate region were notified registered client in misorder due to switching primary queue Key: GEODE-9522 URL: https://issues.apache.org/jira/browse/GEODE-9522 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou When a client is doing puts (mainly creates) to servers with replicated region, shutdown some servers to force switching of primary HARegionQueue, sometimes, the event with later event id is distributed by previous primary HARegionQueue, which caused the events with earlier event ids are rejected by clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9496) Enhance the usage of newly introduced system property
[ https://issues.apache.org/jira/browse/GEODE-9496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9496. -- Fix Version/s: 1.15.0 Assignee: Xiaojian Zhou Resolution: Fixed > Enhance the usage of newly introduced system property > - > > Key: GEODE-9496 > URL: https://issues.apache.org/jira/browse/GEODE-9496 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > In GEODE-9346, I introduced a new system property > enableQueryRetryOnPdxSerializationException in hard-coded way. > We can use SystemPropertyHelper to avoid hard-coded usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9496) Enhance the usage of newly introduced system property
Xiaojian Zhou created GEODE-9496: Summary: Enhance the usage of newly introduced system property Key: GEODE-9496 URL: https://issues.apache.org/jira/browse/GEODE-9496 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou In GEODE-9346, I introduced a new system property enableQueryRetryOnPdxSerializationException in hard-coded way. We can use SystemPropertyHelper to avoid hard-coded usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17418943#comment-17418943 ] Xiaojian Zhou commented on GEODE-9522: -- A detailed description of the issue and fix is here: When the membership received a request to remove itself from locator (this could be triggered by playDead), it will call GMSMembership.forceDisconnect() to close its DM then cache. However, the uncleanShutdownDS() which is running in DisconnectThread could take a few seconds (6-10) to close all the connections before it set shutdownCause in DM (which is used to trigger cancel exception in c/s request or distribution). Since it's running in a separate thread, the membership thought the forceDisconnect() is done while it's still closing connections. During this time windows, a client could re-initiate a ServerConnection, which could put event to cache and HARegionQueue. Those ServerConnection should be prevented in this time window because it will cause data mismatch. The idea to fix is to set shutdownCause in DM as early as possible (before closing connection). It will prevent the incoming AcceptorImpl socket request by triggering cancel exception. > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-9636: - Labels: GeodeOperationAPI (was: ) > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17420038#comment-17420038 ] Xiaojian Zhou commented on GEODE-9636: -- The NoClassDefFoundError is due to other lucene jar is uplift to 7.1.0, but one component did not. I have a fix. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-9636: Assignee: Xiaojian Zhou > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0 > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
[ https://issues.apache.org/jira/browse/GEODE-9705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9705. -- Fix Version/s: 1.15.0 Resolution: Fixed > When create PR failed with DistributedSystemDisconnectedException, should use > it as cause of PartitionedRegionException > --- > > Key: GEODE-9705 > URL: https://issues.apache.org/jira/browse/GEODE-9705 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When PR failed with register itself, it will throw > DistributedSystemDisconnectedException in cleanupFailedInitialization(). > LockServiceDestroyedException should be the cause of > DistributedSystemDisconnectedException. > Currently, we throw PartitionedRegionException directly using > LockServiceDestroyedException, which is not expected. > The fix is to throw PartitionedRegionException using > DistributedSystemDisconnectedException (or any other RuntimeException) as > cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428336#comment-17428336
]
Xiaojian Zhou commented on GEODE-9677:
--
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428336#comment-17428336
]
Xiaojian Zhou edited comment on GEODE-9677 at 10/13/21, 4:39 PM:
-
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
I have a fix.
was (Author: zhouxj):
This is a test issue. The GII provider sends back ImageReply to requester then
it goes on to do finally part. But requester could receive and process the
ImageReply before requester finished processing the finally part. It's a very
tiny window.
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9677:
Assignee: Xiaojian Zhou
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou updated GEODE-9677:
-
Labels: GeodeOperationAPI needsTriage (was: needsTriage)
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
Xiaojian Zhou created GEODE-9715:
Summary: CI: AvailablePortHelperIntegrationTest
getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
in use
Key: GEODE-9715
URL: https://issues.apache.org/jira/browse/GEODE-9715
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
{code:java}
AvailablePortHelperIntegrationTest >
getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
FAILED
java.io.UncheckedIOException: java.net.BindException: Address already in
use (Bind failed)
at
org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
at
org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
at
java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
at
org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
Caused by:
java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:390)
at java.net.ServerSocket.bind(ServerSocket.java:344)
at
org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
... 4 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9715) CI: AvailablePortHelperIntegrationTest getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already in use
[
https://issues.apache.org/jira/browse/GEODE-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17427381#comment-17427381
]
Xiaojian Zhou commented on GEODE-9715:
--
Accoding to Dale, CI no longer runs each test class in its own Docker
container. So tests can conflict with each other. If two tests try to bind to
the same port, one will fail.
So it's a test issue. Should not be any blocker.
> CI: AvailablePortHelperIntegrationTest
> getRandomAvailableTCPPortRange_returnsUsablePorts failed with Address already
> in use
> ---
>
> Key: GEODE-9715
> URL: https://issues.apache.org/jira/browse/GEODE-9715
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Labels: needsTriage
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/integration-test-openjdk8/builds/259
> {code:java}
> AvailablePortHelperIntegrationTest >
> getRandomAvailableTCPPortRange_returnsUsablePorts(useMembershipPortRange=true)
> FAILED
> java.io.UncheckedIOException: java.net.BindException: Address already in
> use (Bind failed)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:280)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.lambda$getRandomAvailableTCPPortRange_returnsUsablePorts$0(AvailablePortHelperIntegrationTest.java:87)
> at
> java.util.Spliterators$IntArraySpliterator.forEachRemaining(Spliterators.java:1032)
> at java.util.stream.IntPipeline$Head.forEach(IntPipeline.java:581)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest.getRandomAvailableTCPPortRange_returnsUsablePorts(AvailablePortHelperIntegrationTest.java:86)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:390)
> at java.net.ServerSocket.bind(ServerSocket.java:344)
> at
> org.apache.geode.internal.AvailablePortHelperIntegrationTest$PortAssertion.isUsable(AvailablePortHelperIntegrationTest.java:273)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-9581) SerialWANStatsDUnitTest > testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend fails
[
https://issues.apache.org/jira/browse/GEODE-9581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reopened GEODE-9581:
--
It's reproduced in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899468
revision f41a1c56dbca3b4bfab159be217201aefd09be81
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSend
> fails
> ---
>
> Key: GEODE-9581
> URL: https://issues.apache.org/jira/browse/GEODE-9581
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In this run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1583
> SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> failed:
> {code:java}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients
> FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.checkQueuesAreEmptyAndOnlyCompleteTransactionsAreReplicated(SerialWANStatsDUnitTest.java:949)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:309)
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationWithGroupTransactionEventsWithoutBatchRedistributionSendsBatchesWithCompleteTransactions_SeveralClients(SerialWANStatsDUnitTest.java:218)
> {code}
> This is a new test. It failed in the mass test run.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
Xiaojian Zhou created GEODE-9714:
Summary: CI: QueryConfigurationServiceConstraintsDistributedTest
failed with java.io.InvalidClassException:
org.apache.shiro.session.StoppedSessionException
Key: GEODE-9714
URL: https://issues.apache.org/jira/browse/GEODE-9714
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
{code:java}
QueryConfigurationServiceConstraintsDistributedTest > [10]
indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in 'dunit_suspect-vm2.log' at line 357
[fatal 2021/10/09 19:11:41.270 UTC
tid=33] Serialization filter is rejecting class
org.apache.shiro.session.StoppedSessionException
java.io.InvalidClassException:
org.apache.shiro.session.StoppedSessionException
at
org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
at
java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
at
org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
at
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
at
org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
at
org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
at
org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
at
org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
at
org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
at
org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
at
org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
at
org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
at
org.apache.geode.internal.cache.LocalRegion.serverDestroy(LocalRegion.java:3095)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforeDestroy(LocalRegion.java:2972)
at
org.apache.geode.internal.cache.ProxyRegionMap.destroy(ProxyRegionMap.java:172)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6507)
at
org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6481)
at
org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:59)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6432)
at
org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1126)
at
org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:)
at
org.apache.geode.internal.cache.AbstractRegion.destroy(AbstractRegion.java:434)
at
[jira] [Assigned] (GEODE-9714) CI: QueryConfigurationServiceConstraintsDistributedTest failed with java.io.InvalidClassException: org.apache.shiro.session.StoppedSessionException
[
https://issues.apache.org/jira/browse/GEODE-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9714:
Assignee: Kirk Lund
> CI: QueryConfigurationServiceConstraintsDistributedTest failed with
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> ---
>
> Key: GEODE-9714
> URL: https://issues.apache.org/jira/browse/GEODE-9714
> Project: Geode
> Issue Type: Bug
>Reporter: Xiaojian Zhou
>Assignee: Kirk Lund
>Priority: Major
> Labels: needsTriage
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11899355
> {code:java}
> QueryConfigurationServiceConstraintsDistributedTest > [10]
> indexesShouldNotBeAffectedByMethodAuthorizerChangeAfterRegionOperationOnClientWhenIndexedExpressionContainsMethodsAllowedByTheNewAuthorizer(RegionType:REPLICATE;Operation:DESTROY)
> FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in 'dunit_suspect-vm2.log' at line 357
> [fatal 2021/10/09 19:11:41.270 UTC
> tid=33] Serialization filter is rejecting class
> org.apache.shiro.session.StoppedSessionException
> java.io.InvalidClassException:
> org.apache.shiro.session.StoppedSessionException
> at
> org.apache.geode.internal.ObjectInputStreamFilterWrapper.lambda$createSerializationFilter$0(ObjectInputStreamFilterWrapper.java:215)
> at com.sun.proxy.$Proxy44.checkInput(Unknown Source)
> at java.io.ObjectInputStream.filterCheck(ObjectInputStream.java:1315)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1996)
> at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1850)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2160)
> at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1667)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:503)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:461)
> at
> org.apache.geode.internal.InternalDataSerializer.readSerializable(InternalDataSerializer.java:2695)
> at
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
> at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
> at
> org.apache.geode.internal.util.BlobHelper.deserializeBlob(BlobHelper.java:102)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheServerHelper.deserialize(CacheServerHelper.java:73)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:354)
> at
> org.apache.geode.internal.cache.tier.sockets.Part.getObject(Part.java:362)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processAck(AbstractOp.java:258)
> at
> org.apache.geode.cache.client.internal.DestroyOp$DestroyOpImpl.processResponse(DestroyOp.java:176)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:212)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:387)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:358)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:757)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:150)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:801)
> at
> org.apache.geode.cache.client.internal.DestroyOp.execute(DestroyOp.java:87)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.destroy(ServerRegionProxy.java:195)
> at
> org.apache.geode.internal.cache.LocalRegion.serverDestroy(LocalRegion.java:3095)
> at
> org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforeDestroy(LocalRegion.java:2972)
> at
> org.apache.geode.internal.cache.ProxyRegionMap.destroy(ProxyRegionMap.java:172)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6507)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6481)
> at
>
[jira] [Commented] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17430236#comment-17430236 ] Xiaojian Zhou commented on GEODE-7309: -- This is related with https://issues.apache.org/jira/browse/GEODE-9636. Next time when this ticket is re-implemented and merged, should merge 9636's pull request too. > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9705) When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException
Xiaojian Zhou created GEODE-9705: Summary: When create PR failed with DistributedSystemDisconnectedException, should use it as cause of PartitionedRegionException Key: GEODE-9705 URL: https://issues.apache.org/jira/browse/GEODE-9705 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou When PR failed with register itself, it will throw DistributedSystemDisconnectedException in cleanupFailedInitialization(). LockServiceDestroyedException should be the cause of DistributedSystemDisconnectedException. Currently, we throw PartitionedRegionException directly using LockServiceDestroyedException, which is not expected. The fix is to throw PartitionedRegionException using DistributedSystemDisconnectedException (or any other RuntimeException) as cause, then set LockServiceDestroyedException as the cause of the cause. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
[
https://issues.apache.org/jira/browse/GEODE-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou resolved GEODE-9677.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
>
>
> Key: GEODE-9677
> URL: https://issues.apache.org/jira/browse/GEODE-9677
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.15.0
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
> {code:java}
> GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotEquals(Assert.java:835)
> at org.junit.Assert.assertEquals(Assert.java:647)
> at org.junit.Assert.assertEquals(Assert.java:633)
> at
> org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9522) When a server is force disconnected, it should set shutdown cause for dm to prevent clients recreating server connection.
[ https://issues.apache.org/jira/browse/GEODE-9522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9522. -- Fix Version/s: 1.15.0 Resolution: Fixed > When a server is force disconnected, it should set shutdown cause for dm to > prevent clients recreating server connection. > - > > Key: GEODE-9522 > URL: https://issues.apache.org/jira/browse/GEODE-9522 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > When a client is doing puts (mainly creates) to servers with replicated > region, shutdown some servers to force switching of primary HARegionQueue, > sometimes, the event with later event id is distributed by previous primary > HARegionQueue, which caused the events with earlier event ids are rejected by > clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9636) CI failure: NoClassDefFoundError in lucene examples
[ https://issues.apache.org/jira/browse/GEODE-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424233#comment-17424233 ] Xiaojian Zhou commented on GEODE-9636: -- It's waiting for GEODE-7309. Currently GEODE-7309 was reverted, so this ticket can also be closed or pending, until GEODE-7309 is remerged again. If GEODE-7309 will not be in 1.15, then this ticket should not be 1.15 release blocker. > CI failure: NoClassDefFoundError in lucene examples > --- > > Key: GEODE-9636 > URL: https://issues.apache.org/jira/browse/GEODE-9636 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Darrel Schneider >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > > The lucene examples have started failing (3 runs in a row) with the following > exceptions: > org.apache.geode_examples.luceneSpatial.TrainStopSerializerTest > > serializerReturnsSingleDocument FAILED > java.lang.NoClassDefFoundError at TrainStopSerializerTest.java:30 > Caused by: java.lang.ClassNotFoundException at > TrainStopSerializerTest.java:30 > org.apache.geode_examples.luceneSpatial.SpatialHelperTest > > queryFindsADocumentThatWasAdded FAILED > java.lang.NoClassDefFoundError at SpatialHelperTest.java:45 > The first failed run was: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-examples/jobs/test-examples/builds/243 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9675) CI: ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
Xiaojian Zhou created GEODE-9675:
Summary: CI: ClusterDistributionManagerDUnitTest >
testConnectAfterBeingShunned FAILED
Key: GEODE-9675
URL: https://issues.apache.org/jira/browse/GEODE-9675
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/1983
{code:java}
ClusterDistributionManagerDUnitTest > testConnectAfterBeingShunned FAILED
org.apache.geode.SystemConnectException: Problem starting up membership
services
at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
at
org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:466)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:499)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:328)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:757)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:133)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3013)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:283)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:209)
at
org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:180)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:256)
at
org.apache.geode.distributed.internal.ClusterDistributionManagerDUnitTest.testConnectAfterBeingShunned(ClusterDistributionManagerDUnitTest.java:170)
Caused by:
org.apache.geode.distributed.internal.membership.api.MemberStartupException:
unable to create jgroups channel
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:401)
at
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1642)
at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
... 13 more
Caused by:
java.lang.Exception: failed to open a port in range 41003-41003
at
org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
at org.jgroups.protocols.UDP.start(UDP.java:266)
at
org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:397)
... 16 more
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9677) CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
Xiaojian Zhou created GEODE-9677:
Summary: CI: GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC
FAILED
Key: GEODE-9677
URL: https://issues.apache.org/jira/browse/GEODE-9677
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/11846626
{code:java}
GIIDeltaDUnitTest > testExpiredTombstoneSkippedGC FAILED
java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:89)
at org.junit.Assert.failNotEquals(Assert.java:835)
at org.junit.Assert.assertEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:633)
at
org.apache.geode.internal.cache.GIIDeltaDUnitTest.testExpiredTombstoneSkippedGC(GIIDeltaDUnitTest.java:1534)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8644. -- Fix Version/s: 1.15.0 Resolution: Fixed > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > Fix For: 1.15.0 > > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Reopened] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reopened GEODE-9060: -- Need to backport it to 1.12, 1.13, 1.14 according to the requirements. > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9060) checkMyStateOnMemebers is better not to change the replicates
[ https://issues.apache.org/jira/browse/GEODE-9060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9060. -- Fix Version/s: 1.12.8 1.13.7 1.14.3 Resolution: Fixed > checkMyStateOnMemebers is better not to change the replicates > - > > Key: GEODE-9060 > URL: https://issues.apache.org/jira/browse/GEODE-9060 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.8, 1.13.7, 1.14.3, 1.15.0 > > > This is an enhancement to previous GEODE-9003. > The previous fix will remove the members in replicates if it cannot recognize > current member, thus these removed members will not acting as GII provider > candidates. The fix is correct. > However, Dan suggested to keep the replicates as is to be more conservative. > These members will still act as GII provider candidates even they cannot > recognize current member due to the split-brain. Conceptually these members > should be the same as other online members. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou resolved GEODE-9747.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9428) CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error
[
https://issues.apache.org/jira/browse/GEODE-9428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444708#comment-17444708
]
Xiaojian Zhou commented on GEODE-9428:
--
Rerproduced in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/12258055
> CI Failure: NativeRedisAcceptanceTest fails with CLUSTERDOWN error
> --
>
> Key: GEODE-9428
> URL: https://issues.apache.org/jira/browse/GEODE-9428
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Hale Bales
>Priority: Major
>
> *This ticket tracks failures seen in NativeRedisAcceptanceTests due to
> non-Geode code. It is closed because no work will be done in the Geode
> project to fix this issue. If the issue becomes unbearable, a bug should be
> opened with Redis:
> [https://github.com/redis/redis/issues|https://github.com/redis/redis/issues*]*
> CI run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk11/builds/82#L60e11384:311]
> {code:java}
> org.apache.geode.redis.internal.executor.string.PSetEXNativeRedisAcceptanceTest
> > testPSetEX FAILED
> redis.clients.jedis.exceptions.JedisClusterException: CLUSTERDOWN The
> cluster is down
> at redis.clients.jedis.Protocol.processError(Protocol.java:125)
> at redis.clients.jedis.Protocol.process(Protocol.java:169)
> at redis.clients.jedis.Protocol.read(Protocol.java:223)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:352)
> at
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:270)
> at redis.clients.jedis.Jedis.psetex(Jedis.java:3616)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:572)
> at redis.clients.jedis.JedisCluster$30.execute(JedisCluster.java:569)
> at
> redis.clients.jedis.JedisClusterCommand.runWithRetries(JedisClusterCommand.java:121)
> at
> redis.clients.jedis.JedisClusterCommand.run(JedisClusterCommand.java:45)
> at redis.clients.jedis.JedisCluster.psetex(JedisCluster.java:574)
> at
> org.apache.geode.redis.internal.executor.string.AbstractPSetEXIntegrationTest.testPSetEX(AbstractPSetEXIntegrationTest.java:54)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.apache.geode.redis.NativeRedisClusterTestRule$1.evaluate(NativeRedisClusterTestRule.java:120)
> at
> org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
>
[jira] [Created] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
Xiaojian Zhou created GEODE-9810:
Summary: CI: NativeRedisClusterTest
testEachProxyReturnsExposedPorts failed
Key: GEODE-9810
URL: https://issues.apache.org/jira/browse/GEODE-9810
Project: Geode
Issue Type: Bug
Components: redis
Reporter: Xiaojian Zhou
https://hydradb.hdb.gemfire-ci.info/hdb/testresult/12258442
{code:java}
> Task :geode-for-redis:acceptanceTest
NativeRedisClusterTest > testEachProxyReturnsExposedPorts FAILED
java.lang.AssertionError:
Expecting actual:
[44073, 45679, 36065, 40077, 42137]
to contain exactly in any order:
[40077, 45679, 33425, 36065, 42137, 44073]
but could not find the following elements:
[33425]
at
org.apache.geode.redis.NativeRedisClusterTest.testEachProxyReturnsExposedPorts(NativeRedisClusterTest.java:48)
1385 tests completed, 1 failed, 2 skipped
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-artifacts/1637046056/acceptancetestfiles-openjdk8-1.15.0-build.0662.tgz
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
[
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou resolved GEODE-9850.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> First saw this failure in PR pipeline on support/1.13 here:
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
> in VM 0 running on Host 9a305b2d7db7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <-1637701703343L>
> to be greater than:
> <0L>
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
> {code}
> I believe the fix is to wrap this assertion in an awaitility call.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17447573#comment-17447573 ] Xiaojian Zhou commented on GEODE-8644: -- The reproduced failures are all caused by locator disconnected: [locator] [info 2021/11/13 08:43:12.331 UTC tid=0x46] Failed to connect to localhost/127.0.0.1:0 [locator] [warn 2021/11/13 08:43:12.331 UTC tid=0x46] Locator discovery task for locator heavy-lifter-ca6688de-b95d-5db6-9ac5-57db242f6302.c.apachegeode-ci.internal[34223] could not exchange locator information with localhost[0] after 45 retry attempts. Retrying in 1 ms. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9838) Log key info for deserilation issue while index update
[
https://issues.apache.org/jira/browse/GEODE-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9838:
Assignee: Xiaojian Zhou
> Log key info for deserilation issue while index update
> ---
>
> Key: GEODE-9838
> URL: https://issues.apache.org/jira/browse/GEODE-9838
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.15.0
>Reporter: Anilkumar Gingade
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI
>
> When there is issue in Index update (maintenance); the index is marked as
> invalid. And warning is logged:
> [warn 2021/11/11 07:39:28.215 CST pazrslsrv004 Processor 963> tid=0x124ecf] Updating the Index patientMemberIdentifier
> failed. The index is corrupted and marked as invalid.
> org.apache.geode.cache.query.internal.index.IMQException
> Adding "key" information in the log helps diagnosing the failure and adding
> or removing the entry in question.
> Code path IndexManager.java:
> void addIndexMapping(RegionEntry entry, IndexProtocol index) {
> try {
> index.addIndexMapping(entry);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
> void removeIndexMapping(RegionEntry entry, IndexProtocol index, int opCode) {
> try {
> index.removeIndexMapping(entry, opCode);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9838) Log key info for deserilation issue while index update
[
https://issues.apache.org/jira/browse/GEODE-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou resolved GEODE-9838.
--
Fix Version/s: 1.12.6
1.13.5
1.14.1
1.15.0
Resolution: Fixed
> Log key info for deserilation issue while index update
> ---
>
> Key: GEODE-9838
> URL: https://issues.apache.org/jira/browse/GEODE-9838
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.15.0
>Reporter: Anilkumar Gingade
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0
>
>
> When there is issue in Index update (maintenance); the index is marked as
> invalid. And warning is logged:
> [warn 2021/11/11 07:39:28.215 CST pazrslsrv004 Processor 963> tid=0x124ecf] Updating the Index patientMemberIdentifier
> failed. The index is corrupted and marked as invalid.
> org.apache.geode.cache.query.internal.index.IMQException
> Adding "key" information in the log helps diagnosing the failure and adding
> or removing the entry in question.
> Code path IndexManager.java:
> void addIndexMapping(RegionEntry entry, IndexProtocol index) {
> try {
> index.addIndexMapping(entry);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
> void removeIndexMapping(RegionEntry entry, IndexProtocol index, int opCode) {
> try {
> index.removeIndexMapping(entry, opCode);
> } catch (Exception exception) {
> index.markValid(false);
> setPRIndexAsInvalid((AbstractIndex) index);
> logger.warn(String.format(
> "Updating the Index %s failed. The index is corrupted and marked as
> invalid.",
> ((AbstractIndex) index).indexName), exception);
> }
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
[
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9850:
Assignee: Xiaojian Zhou
> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI
>
> First saw this failure in PR pipeline on support/1.13 here:
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
> in VM 0 running on Host 9a305b2d7db7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <-1637701703343L>
> to be greater than:
> <0L>
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
> {code}
> I believe the fix is to wrap this assertion in an awaitility call.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
[
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou updated GEODE-9850:
-
Labels: GeodeOperationAPI (was: )
> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Priority: Major
> Labels: GeodeOperationAPI
>
> First saw this failure in PR pipeline on support/1.13 here:
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
> in VM 0 running on Host 9a305b2d7db7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <-1637701703343L>
> to be greater than:
> <0L>
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
> {code}
> I believe the fix is to wrap this assertion in an awaitility call.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9850) flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
[
https://issues.apache.org/jira/browse/GEODE-9850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17448310#comment-17448310
]
Xiaojian Zhou commented on GEODE-9850:
--
It's flaky because the destroy(key) might have not created the tombstone yet,
which caused getOldestTombstoneTime() return 0.
> flaky test: testGetOldestTombstoneTimeForReplicateTombstoneSweeper
> --
>
> Key: GEODE-9850
> URL: https://issues.apache.org/jira/browse/GEODE-9850
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.5
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI
>
> First saw this failure in PR pipeline on support/1.13 here:
> [https://concourse.apachegeode-ci.info/builds/3912569]
> {code:java}
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest >
> testGetOldestTombstoneTimeForReplicateTombstoneSweeper FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest$$Lambda$42/2046302475.run
> in VM 0 running on Host 9a305b2d7db7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.testGetOldestTombstoneTimeForReplicateTombstoneSweeper(TombstoneDUnitTest.java:228)
> Caused by:
> java.lang.AssertionError:
> Expecting:
> <-1637701703343L>
> to be greater than:
> <0L>
> at
> org.apache.geode.internal.cache.versions.TombstoneDUnitTest.lambda$testGetOldestTombstoneTimeForReplicateTombstoneSweeper$bb17a952$3(TombstoneDUnitTest.java:237)
> {code}
> I believe the fix is to wrap this assertion in an awaitility call.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xiaojian Zhou reassigned GEODE-9747:
Assignee: Xiaojian Zhou
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9747) CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of exception
[
https://issues.apache.org/jira/browse/GEODE-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17440837#comment-17440837
]
Xiaojian Zhou commented on GEODE-9747:
--
This is caused by my fix GEODE-9705, where I saved the exceptions which were
originally ignored in cleanupFailedInitialization(). I only keep the first
exception and ignore later exceptions.
cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown() will purposely
close the cache and cause creating PR failed with CacheClosedException or disk
recovery exception.
Before my code changes in GEODE-9705, all these exceptions in
cleanupFailedInitialization() will be ignored. Then it will go further and fail
in later steps.
This time, it failed in
{code:java}
[vm0] [warn 2021/10/16 04:50:40.769 UTC
tid=0x21] PartitionedRegion#cleanupFailedInitialization(): Failed to clean the
PartionRegion data store
[vm0] org.apache.geode.distributed.DistributedSystemDisconnectedException: This
connection to a distributed system has been disconnected.
[vm0] at
org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:957)
[vm0] at
org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1658)
[vm0] at
org.apache.geode.distributed.internal.ReplyProcessor21.getDistributionManager(ReplyProcessor21.java:366)
[vm0] at
org.apache.geode.distributed.internal.ReplyProcessor21.postWait(ReplyProcessor21.java:592)
[vm0] at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:818)
[vm0] at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:773)
[vm0] at
org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:859)
[vm0] at
org.apache.geode.internal.cache.PartitionedRegion.attemptToSendDestroyRegionMessage(PartitionedRegion.java:7592)
[vm0] at
org.apache.geode.internal.cache.PartitionedRegion.sendDestroyRegionMessage(PartitionedRegion.java:7553)
[vm0] at
org.apache.geode.internal.cache.PartitionedRegion.cleanupFailedInitialization(PartitionedRegion.java:5577)
{code}
Depends on timing, most of the time the test will not fail here and it will
still throw the expected CacheClosedException. But occasionally it will fail
here, and this exception is not expected by the test.
I can change the product code to save the last exception instead of the first
exception to fix the bug. But after thought over, it's better to fix the test
code and add this expected exception as long as we know what's going on.
> CI failure: PersistentPartitionedRegionDistributedTest sees wrong kind of
> exception
> ---
>
> Key: GEODE-9747
> URL: https://issues.apache.org/jira/browse/GEODE-9747
> Project: Geode
> Issue Type: Bug
> Components: core, tests
>Affects Versions: 1.15.0
>Reporter: Bill Burcham
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> May be the same issue as GEODE-7030 but it's hard to tell since that other
> ticket is short on details.
> {noformat}
> PersistentPartitionedRegionDistributedTest >
> cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionDistributedTest$$Lambda$331/778323733.run
> in VM 0 running on Host
> heavy-lifter-2597c5be-686f-56ce-ab29-4c643f8174ba.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.cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown(PersistentPartitionedRegionDistributedTest.java:1129)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> 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.partitioned.PersistentPartitionedRegionDistributedTest.lambda$cacheIsClosedWhenConflictingPersistentDataExceptionIsThrown$bb17a952$4(PersistentPartitionedRegionDistributedTest.java:1136)
> {noformat}
--
This message was sent by Atlassian Jira
[jira] [Resolved] (GEODE-9729) CI Failure: PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED
[ https://issues.apache.org/jira/browse/GEODE-9729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-9729. -- Fix Version/s: 1.15.0 Assignee: Xiaojian Zhou Resolution: Fixed > CI Failure: > PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs FAILED > - > > Key: GEODE-9729 > URL: https://issues.apache.org/jira/browse/GEODE-9729 > Project: Geode > Issue Type: Bug > Components: client/server >Affects Versions: 1.15.0 >Reporter: Eric Shu >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > Fix For: 1.15.0 > > > org.apache.geode.cache.client.AllConnectionsInUseException > at > org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:304) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:137) > at > org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:120) > at > org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:805) > at > org.apache.geode.cache.client.internal.GetClientPRMetaDataOp.execute(GetClientPRMetaDataOp.java:53) > at > org.apache.geode.cache.client.internal.ClientMetadataService.getClientPRMetadata(ClientMetadataService.java:574) > at > org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:972) > at > org.awaitility.core.AssertionCondition.lambda$new$0(AssertionCondition.java:53) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:234) > at > org.awaitility.core.ConditionAwaiter$ConditionPoller.call(ConditionAwaiter.java:221) > at java.util.concurrent.FutureTask.run(FutureTask.java:264) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.lang.Thread.run(Thread.java:829) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17456592#comment-17456592 ] Xiaojian Zhou commented on GEODE-8644: -- "Failed to connect to localhost/127.0.0.1:0" error message was introduced in Geode-7751. But introducing this error message itself is not the root cause. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[
https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454924#comment-17454924
]
Xiaojian Zhou commented on GEODE-8644:
--
What raised my attention is:
1) In all failed tests, there're
{code:java}
[vm5] [info 2021/12/04 03:37:28.229 UTC tid=0x69] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm5] [info 2021/12/04 03:37:28.230 UTC tid=0x69] Socket send
buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket send
buffer size is 212992 instead of the requested 524288.
{code}
In the passed tests, there's no such message.
2) There're much more locator error message:
{code:java}
[locator] [info 2021/12/04 03:37:42.421 UTC
tid=0x46] Failed to connect to localhost/127.0.0.1:0
{code}
In passed tests, there're about less than 5 of these messages, but in failed
tests, there're 15-20 of these message.
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely()
> intermittently fails when queues drain too slowly
> ---
>
> Key: GEODE-8644
> URL: https://issues.apache.org/jira/browse/GEODE-8644
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Benjamin P Ross
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> Currently the test
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely()
> relies on a 2 second delay to allow for queues to finish draining after
> finishing the put operation. If queues take longer than 2 seconds to drain
> the test will fail. We should change the test to wait for the queues to be
> empty with a long timeout in case the queues never fully drain.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Comment Edited] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[
https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17454924#comment-17454924
]
Xiaojian Zhou edited comment on GEODE-8644 at 12/8/21, 1:44 AM:
What raised my attention are:
1) In all failed tests, there're
{code:java}
[vm5] [info 2021/12/04 03:37:28.229 UTC tid=0x69] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm5] [info 2021/12/04 03:37:28.230 UTC tid=0x69] Socket send
buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket send
buffer size is 212992 instead of the requested 524288.
{code}
In the passed tests, there's no such message.
BTW, this could happen after Bill's fix in "GEODE-9825".
2) There're much more locator error message:
{code:java}
[locator] [info 2021/12/04 03:37:42.421 UTC
tid=0x46] Failed to connect to localhost/127.0.0.1:0
{code}
In passed tests, there're about less than 5 of these messages, but in failed
tests, there're 15-20 of these message.
was (Author: zhouxj):
What raised my attention is:
1) In all failed tests, there're
{code:java}
[vm5] [info 2021/12/04 03:37:28.229 UTC tid=0x69] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm5] [info 2021/12/04 03:37:28.230 UTC tid=0x69] Socket send
buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket
receive buffer size is 212992 instead of the requested 524288.
[vm4] [info 2021/12/04 03:37:32.891 UTC tid=0x6c] Socket send
buffer size is 212992 instead of the requested 524288.
{code}
In the passed tests, there's no such message.
2) There're much more locator error message:
{code:java}
[locator] [info 2021/12/04 03:37:42.421 UTC
tid=0x46] Failed to connect to localhost/127.0.0.1:0
{code}
In passed tests, there're about less than 5 of these messages, but in failed
tests, there're 15-20 of these message.
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely()
> intermittently fails when queues drain too slowly
> ---
>
> Key: GEODE-8644
> URL: https://issues.apache.org/jira/browse/GEODE-8644
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Benjamin P Ross
>Assignee: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage, pull-request-available
>
> Currently the test
> SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely()
> relies on a 2 second delay to allow for queues to finish draining after
> finishing the put operation. If queues take longer than 2 seconds to drain
> the test will fail. We should change the test to wait for the queues to be
> empty with a long timeout in case the queues never fully drain.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-8644: Assignee: Xiaojian Zhou (was: Mark Hanson) > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8644) SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() intermittently fails when queues drain too slowly
[ https://issues.apache.org/jira/browse/GEODE-8644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460939#comment-17460939 ] Xiaojian Zhou commented on GEODE-8644: -- The root cause is: When CME happened, notifyTimestampsToGateways() will be called in AbstractRegionMap. The gateway event with UPDATE_VERSION operation will be enqueued. At the server as secondary queue holder, this event is ignored, not to call handleSecondaryEvent(). But at the primary queue holder, this event will still be queued and add a unprocessedToken. Since there's no corresponding event will arrive at secondary queue to trigger removal of the token, when this scenario happen, the tokens will always be leaked. It's a very old code and behavior, as old as in 8.2. We did not find this problem earlier is due to 2 reasons: 1) It's a rarely happened race. 2) We did not have a test to purposely test unprocessedToken draining until GEODE-7643 introduced one. There're several ways to fix it: One alternative is not to enqueue this kind of event into primary queue, like what we did in secondary queue. But this alternative changed current logic and assumption and it's risky. So I choose only not to add into unprocessedTokens for this kind of event. This fix is very conservative. > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > intermittently fails when queues drain too slowly > --- > > Key: GEODE-8644 > URL: https://issues.apache.org/jira/browse/GEODE-8644 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Benjamin P Ross >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI, needsTriage, pull-request-available > > Currently the test > SerialGatewaySenderQueueDUnitTest.unprocessedTokensMapShouldDrainCompletely() > relies on a 2 second delay to allow for queues to finish draining after > finishing the put operation. If queues take longer than 2 seconds to drain > the test will fail. We should change the test to wait for the queues to be > empty with a long timeout in case the queues never fully drain. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10118) PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in clearShouldFailWhenCoordinatorMemberIsBounced
Xiaojian Zhou created GEODE-10118: - Summary: PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in clearShouldFailWhenCoordinatorMemberIsBounced Key: GEODE-10118 URL: https://issues.apache.org/jira/browse/GEODE-10118 Project: Geode Issue Type: Bug Affects Versions: 1.16.0 Reporter: Xiaojian Zhou In PR Clear feature branch, after rebase merged in GEODE-9522, clusterDistributionManager setRootCause before TCPConduit.stop. It could cause restarting of server hang after force disconnect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10118) PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in clearShouldFailWhenCoordinatorMemberIsBounced
[ https://issues.apache.org/jira/browse/GEODE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17504724#comment-17504724 ] Xiaojian Zhou commented on GEODE-10118: --- This is for PR clear feature branch only. Not for any releases yet. > PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in > clearShouldFailWhenCoordinatorMemberIsBounced > --- > > Key: GEODE-10118 > URL: https://issues.apache.org/jira/browse/GEODE-10118 > Project: Geode > Issue Type: Sub-task >Affects Versions: 1.16.0 >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > In PR Clear feature branch, after rebase merged in GEODE-9522, > clusterDistributionManager setRootCause before TCPConduit.stop. It could > cause restarting of server hang after force disconnect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10118) PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in clearShouldFailWhenCoordinatorMemberIsBounced
[ https://issues.apache.org/jira/browse/GEODE-10118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-10118: -- Parent: GEODE-7665 Issue Type: Sub-task (was: Bug) > PartitionedRegionClearWithConcurrentOperationsDUnitTest will hang in > clearShouldFailWhenCoordinatorMemberIsBounced > --- > > Key: GEODE-10118 > URL: https://issues.apache.org/jira/browse/GEODE-10118 > Project: Geode > Issue Type: Sub-task >Affects Versions: 1.16.0 >Reporter: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > In PR Clear feature branch, after rebase merged in GEODE-9522, > clusterDistributionManager setRootCause before TCPConduit.stop. It could > cause restarting of server hang after force disconnect. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10113) CI: AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() FAILED
Xiaojian Zhou created GEODE-10113: - Summary: CI: AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions() FAILED Key: GEODE-10113 URL: https://issues.apache.org/jira/browse/GEODE-10113 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou > Task :geode-core:test AutoConnectionSourceImplTest > queryLocatorsTriesNextLocatorOnSSLExceptions() FAILED java.lang.AssertionError: Expecting actual: Mock for ServerLocationResponse, hashCode: 186159903 and actual: null to refer to the same object at org.apache.geode.cache.client.internal.AutoConnectionSourceImplTest.queryLocatorsTriesNextLocatorOnSSLExceptions(AutoConnectionSourceImplTest.java:91) 7320 tests completed, 1 failed, 11 skipped It's found in https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/windows-unit-test-openjdk11/builds/187 It's said to be similar to GEODE-10066 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-974) CI Failure: PersistentPartitionedRegionDUnitTest.testRevokeBeforeStartup failed with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17503084#comment-17503084
]
Xiaojian Zhou commented on GEODE-974:
-
I found it reproduced in
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/194
> 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
>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
>
[jira] [Reopened] (GEODE-9998) Update jedis library to the current latest (>= 4.1.0)
[ https://issues.apache.org/jira/browse/GEODE-9998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reopened GEODE-9998: -- It caused NoClassDefFoundError in some tests. > Update jedis library to the current latest (>= 4.1.0) > - > > Key: GEODE-9998 > URL: https://issues.apache.org/jira/browse/GEODE-9998 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.16.0 >Reporter: Jens Deppe >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > The 4.x version has been out for a while and we're still on 3.6.x (3.8 is the > last in the 3.x line). > This is not a trivial change as various APIs have changed which will affect a > lot of test code. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9989) add a few info level logs in PersistenceAdvisorImpl to identify splitbrain issue
Xiaojian Zhou created GEODE-9989:
Summary: add a few info level logs in PersistenceAdvisorImpl to
identify splitbrain issue
Key: GEODE-9989
URL: https://issues.apache.org/jira/browse/GEODE-9989
Project: Geode
Issue Type: Bug
Reporter: Xiaojian Zhou
In scenario like:
{code:java}
03:33:03.644 dataStoregemfire4_4494 recovered from disk
03:33:03.732 dataStoregemfire4_4494 closing
03:33:03.735 dataStoregemfire4_4494 Initialization of region replicate_5
completed, send newId(let’s name it 4494) to gemfire2
03:33:03.754 dataStoregemfire2_4493 recovered from disk
03:33:03.770 dataStoregemfire2_4493 closing
03:33:03.792 dataStoregemfire2_4493 Initialization of region replicate_5
completed. send newId(let’s name is 4493) to gemfire4, but gemfire4 is offline.
So gemfire4 does not know gemfire2’s newId 4493.
03:34:11.247 gemfire4_9779 restarted, it does not know 4493
03:34:11.269 gemfire2_9856 restarted, it sends oldId=4493, newId=9856 to
gemfire4, but gemfire4 does not know either of gemfire2’s oldId and newId
When gemfire2_9856 asked gemfire4_9779 for its state, gemfire4_9779 replied "I
don't know you", then gemfire2_9856's starting ends with
ConflictingPersistentDataException.
{code}
We need more log to identify the issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10229) Saving received RVV's caused exception should be filled.
Xiaojian Zhou created GEODE-10229: - Summary: Saving received RVV's caused exception should be filled. Key: GEODE-10229 URL: https://issues.apache.org/jira/browse/GEODE-10229 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou Saving received RVV's caused exception should be filled during processing GII image There's a race in GII: A distribution of operation (RemoveAll could be more obvious) arrived when the member is requesting GII and before saving received RVV. The saveReceivedRVV() will the newly arrived operation to be an exception. In normal case, the exception will be filled in processChunk(). But in above case, the processChunk() will skip the entry because the local entry is not recovered from disk. Thus the exception will stay after GII. To fix it, and not to slow down the performance, we need to check if such exception exists, and do the recordVersion() for this entry. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10229) Saving received RVV's caused exception should be filled.
[ https://issues.apache.org/jira/browse/GEODE-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-10229: - Assignee: Xiaojian Zhou > Saving received RVV's caused exception should be filled. > > > Key: GEODE-10229 > URL: https://issues.apache.org/jira/browse/GEODE-10229 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: needsTriage > > Saving received RVV's caused exception should be filled during processing GII > image > There's a race in GII: > A distribution of operation (RemoveAll could be more obvious) arrived when > the member is requesting GII and before saving received RVV. The > saveReceivedRVV() will the newly arrived operation to be an exception. > In normal case, the exception will be filled in processChunk(). But in above > case, the processChunk() will skip the entry because the local entry is not > recovered from disk. > Thus the exception will stay after GII. > To fix it, and not to slow down the performance, we need to check if such > exception exists, and do the recordVersion() for this entry. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10229) Saving received RVV's caused exception should be filled.
[ https://issues.apache.org/jira/browse/GEODE-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17526242#comment-17526242 ] Xiaojian Zhou commented on GEODE-10229: --- backported into 1.14,1.13,1.12. > Saving received RVV's caused exception should be filled. > > > Key: GEODE-10229 > URL: https://issues.apache.org/jira/browse/GEODE-10229 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > Saving received RVV's caused exception should be filled during processing GII > image > There's a race in GII: > A distribution of operation (RemoveAll could be more obvious) arrived when > the member is requesting GII and before saving received RVV. The > saveReceivedRVV() will the newly arrived operation to be an exception. > In normal case, the exception will be filled in processChunk(). But in above > case, the processChunk() will skip the entry because the local entry is not > recovered from disk. > Thus the exception will stay after GII. > To fix it, and not to slow down the performance, we need to check if such > exception exists, and do the recordVersion() for this entry. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10229) Saving received RVV's caused exception should be filled.
[ https://issues.apache.org/jira/browse/GEODE-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-10229: -- Fix Version/s: 1.12.10 1.13.9 1.14.5 > Saving received RVV's caused exception should be filled. > > > Key: GEODE-10229 > URL: https://issues.apache.org/jira/browse/GEODE-10229 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.0 > > > Saving received RVV's caused exception should be filled during processing GII > image > There's a race in GII: > A distribution of operation (RemoveAll could be more obvious) arrived when > the member is requesting GII and before saving received RVV. The > saveReceivedRVV() will the newly arrived operation to be an exception. > In normal case, the exception will be filled in processChunk(). But in above > case, the processChunk() will skip the entry because the local entry is not > recovered from disk. > Thus the exception will stay after GII. > To fix it, and not to slow down the performance, we need to check if such > exception exists, and do the recordVersion() for this entry. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-7138) CI failure: ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer
[ https://issues.apache.org/jira/browse/GEODE-7138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reopened GEODE-7138: -- Reproduced in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14761766 > CI failure: > ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer > -- > > Key: GEODE-7138 > URL: https://issues.apache.org/jira/browse/GEODE-7138 > Project: Geode > Issue Type: Bug > Components: transactions >Affects Versions: 1.11.0 >Reporter: Anilkumar Gingade >Assignee: Eric Shu >Priority: Major > Labels: GeodeCommons, flaky > Fix For: 1.10.0 > > Time Spent: 20m > Remaining Estimate: 0h > > DistributedTestOpenJDK8 #1035 > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > > clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest$$Lambda$47/1742885319.run > in VM 0 running on Host 13889d5ebaf9 with 6 VMs > at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579) > at org.apache.geode.test.dunit.VM.invoke(VM.java:406) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest > that uses org.apache.geode.cache.Region, org.apache.geode.cache.Regionint > expected:<[144]> but was:<[37]> within 300 seconds. > at > org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122) > at > org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32) > at > org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902) > at > org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.verifyTransactionResult(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$clientTransactionOperationsAreNotLostIfTransactionIsOnRolledServer$2967fbd$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:137) > Caused by: > org.junit.ComparisonFailure: expected:<[144]> but was:<[37]> > at > sun.reflect.GeneratedConstructorAccessor38.newInstance(Unknown Source) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.internal.cache.ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.lambda$verifyTransactionResult$2(ClientServerTransactionFailoverWithMixedVersionServersDistributedTest.java:361) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10229) Saving received RVV's caused exception should be filled.
[ https://issues.apache.org/jira/browse/GEODE-10229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-10229. --- Fix Version/s: 1.15.0 Resolution: Fixed > Saving received RVV's caused exception should be filled. > > > Key: GEODE-10229 > URL: https://issues.apache.org/jira/browse/GEODE-10229 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.0 > > > Saving received RVV's caused exception should be filled during processing GII > image > There's a race in GII: > A distribution of operation (RemoveAll could be more obvious) arrived when > the member is requesting GII and before saving received RVV. The > saveReceivedRVV() will the newly arrived operation to be an exception. > In normal case, the exception will be filled in processChunk(). But in above > case, the processChunk() will skip the entry because the local entry is not > recovered from disk. > Thus the exception will stay after GII. > To fix it, and not to slow down the performance, we need to check if such > exception exists, and do the recordVersion() for this entry. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10247) CI: spring-compatibility-test compile failure
Xiaojian Zhou created GEODE-10247: - Summary: 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 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] [Created] (GEODE-10248) CI: DeployToMultiGroupDUnitTest encountered suspect string
Xiaojian Zhou created GEODE-10248: - Summary: 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 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 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10258) CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED
Xiaojian Zhou created GEODE-10258: - Summary: CI: ClearDuringNetSearchOplogRegressionTest > testQueryGetWithClear FAILED Key: GEODE-10258 URL: https://issues.apache.org/jira/browse/GEODE-10258 Project: Geode Issue Type: Bug Reporter: Xiaojian Zhou 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) -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9617) CI Failure: PartitionedRegionSingleHopDUnitTest fails with ConditionTimeoutException waiting for server to bucket map size
[
https://issues.apache.org/jira/browse/GEODE-9617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17527645#comment-17527645
]
Xiaojian Zhou commented on GEODE-9617:
--
Reproduced in https://hydradb.hdb.gemfire-ci.info/hdb/testresult/14769422
> CI Failure: PartitionedRegionSingleHopDUnitTest fails with
> ConditionTimeoutException waiting for server to bucket map size
> --
>
> Key: GEODE-9617
> URL: https://issues.apache.org/jira/browse/GEODE-9617
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testClientMetadataForPersistentPrs FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest that uses
> org.apache.geode.cache.client.internal.ClientMetadataService,
> org.apache.geode.cache.client.internal.ClientMetadataServiceorg.apache.geode.cache.Region
>
> Expecting actual not to be null within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testClientMetadataForPersistentPrs(PartitionedRegionSingleHopDUnitTest.java:971)
> Caused by:
> java.lang.AssertionError:
> Expecting actual not to be null
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testClientMetadataForPersistentPrs$26(PartitionedRegionSingleHopDUnitTest.java:976)
> {noformat}
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest >
> testMetadataServiceCallAccuracy_FromGetOp FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest that uses
> org.apache.geode.cache.client.internal.ClientMetadataService
> Expecting value to be false but was true expected:<[fals]e> but
> was:<[tru]e> within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataServiceCallAccuracy_FromGetOp(PartitionedRegionSingleHopDUnitTest.java:394)
> Caused by:
> org.junit.ComparisonFailure:
> Expecting value to be false but was true expected:<[fals]e> but
> was:<[tru]e>
> at sun.reflect.GeneratedConstructorAccessor29.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest.lambda$testMetadataServiceCallAccuracy_FromGetOp$6(PartitionedRegionSingleHopDUnitTest.java:395)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-10290. --- Fix Version/s: 1.16.0 Resolution: Fixed > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.16.0 > > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10290) GII requester should remove departed members
[ https://issues.apache.org/jira/browse/GEODE-10290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-10290: -- Fix Version/s: 1.12.10 1.14.5 > GII requester should remove departed members > > > Key: GEODE-10290 > URL: https://issues.apache.org/jira/browse/GEODE-10290 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: blocks-1.15.0, pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0, 1.16.0 > > > In non-persistent but concurrent-check enabled case, members departed will be > marked. They should be removed from RVV during GII to prevent memberToVersion > in RVV grows bigger and bigger. > However, we only removed them from GII provider, not in GII requester. The > good opportunity to remove them in GII requester is when calculating > unfinished operations. -- This message was sent by Atlassian Jira (v8.20.7#820007)
