[jira] [Commented] (GEODE-9769) add pubsub stats to geode-for-redis INFO command
[ https://issues.apache.org/jira/browse/GEODE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444965#comment-17444965 ] ASF subversion and git services commented on GEODE-9769: Commit e6d10c8bbfc3071d1c7f521d897024de405b0e73 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e6d10c8 ] GEODE-9769: add pubsub stats to INFO command (#7100) -- added pubsub_channels and pubsub_patterns to stats section of info command -- added pubsub INFO stats to README.md > add pubsub stats to geode-for-redis INFO command > > > Key: GEODE-9769 > URL: https://issues.apache.org/jira/browse/GEODE-9769 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Standard redis has the following on the INFO command: > pubsub_channels: Global number of pub/sub channels with client subscriptions > pubsub_patterns: Global number of pub/sub pattern with client subscriptions > geode-for-redis has some stats that correspond to these but the stats are > only available from geode's existing stat tools. The two geode stats that > correspond to these are: uniqueChannelSubscriptions and > uniquePatternSubscriptions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9769) add pubsub stats to geode-for-redis INFO command
[ https://issues.apache.org/jira/browse/GEODE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9769. - Fix Version/s: 1.15.0 Resolution: Fixed > add pubsub stats to geode-for-redis INFO command > > > Key: GEODE-9769 > URL: https://issues.apache.org/jira/browse/GEODE-9769 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Standard redis has the following on the INFO command: > pubsub_channels: Global number of pub/sub channels with client subscriptions > pubsub_patterns: Global number of pub/sub pattern with client subscriptions > geode-for-redis has some stats that correspond to these but the stats are > only available from geode's existing stat tools. The two geode stats that > correspond to these are: uniqueChannelSubscriptions and > uniquePatternSubscriptions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9769) add pubsub stats to geode-for-redis INFO command
[ https://issues.apache.org/jira/browse/GEODE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9769: Affects Version/s: 1.15.0 > add pubsub stats to geode-for-redis INFO command > > > Key: GEODE-9769 > URL: https://issues.apache.org/jira/browse/GEODE-9769 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Standard redis has the following on the INFO command: > pubsub_channels: Global number of pub/sub channels with client subscriptions > pubsub_patterns: Global number of pub/sub pattern with client subscriptions > geode-for-redis has some stats that correspond to these but the stats are > only available from geode's existing stat tools. The two geode stats that > correspond to these are: uniqueChannelSubscriptions and > uniquePatternSubscriptions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9566) Geode for Redis No Longer Experimental
[ https://issues.apache.org/jira/browse/GEODE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444964#comment-17444964 ] ASF subversion and git services commented on GEODE-9566: Commit bcb2e3e0e2993053ccaaf833bad99a22191c4962 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bcb2e3e ] GEODE-9566: removed a couple more geode-for-redis Experimental instances (#7102) > Geode for Redis No Longer Experimental > -- > > Key: GEODE-9566 > URL: https://issues.apache.org/jira/browse/GEODE-9566 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Geode for Redis is no longer experimental. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-9566) Geode for Redis No Longer Experimental
[ https://issues.apache.org/jira/browse/GEODE-9566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9566. - Resolution: Fixed > Geode for Redis No Longer Experimental > -- > > Key: GEODE-9566 > URL: https://issues.apache.org/jira/browse/GEODE-9566 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Geode for Redis is no longer experimental. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444936#comment-17444936 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell edited a comment on pull request #894: URL: https://github.com/apache/geode-native/pull/894#issuecomment-971172824 **NOTE:** The integration test failure on ubuntu 16.04 debug is not related to this PR. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[ https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444935#comment-17444935 ] ASF GitHub Bot commented on GEODE-9804: --- mmartell commented on pull request #894: URL: https://github.com/apache/geode-native/pull/894#issuecomment-971172824 **NOTE:** The integration test failure on ubuntu 16.04 debug is not related to this PR: -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Both registerAllKeys and registerRegex always fetch initial entries. > > > Key: GEODE-9804 > URL: https://issues.apache.org/jira/browse/GEODE-9804 > Project: Geode > Issue Type: Bug >Reporter: Jacob Barrett >Priority: Major > Labels: needsTriage, pull-request-available > > A inconsistency and bug in how the two regex interest methods configure the > initial interest policy results in the both registerAllKeys and registerRegex > fetching all initial entries despite the boolean parameter to get initial > entries. Furthermore the misconfiguration results in none of the entries > actually getting sent to the cache listener. The result is unnecessarily long > registration times, network traffic and load on the servers. On servers with > say millions of keys this can result in long GC pauses to unintentionally > iterate over all those keys. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone
Dan Smith created GEODE-9815: Summary: Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone Key: GEODE-9815 URL: https://issues.apache.org/jira/browse/GEODE-9815 Project: Geode Issue Type: Bug Components: regions Affects Versions: 1.15.0 Reporter: Dan Smith The fix in GEODE-9554 is incomplete for some cases, and it also introduces a new issue when removing buckets that are over redundancy. GEODE-9554 and these new issues are all related to using redundancy zones and having persistent members. With persistence, when we start up a member with persisted buckets, we always recover the persisted buckets on startup, regardless of whether redundancy is already met or what zone the existing buckets are on. This is necessary to ensure that we can recover all colocated buckets that might be persisted on the member. Because recovering these persistent buckets may cause us to go over redundancy, after we recover from disk, we run a "restore redundancy" task that actually removes copies of buckets that are over redundancy. GEODE-9554 addressed one case where we end up removing the last copy of a bucket from one redundancy zone while leaving two copies in another redundancy zone. It did so by disallowing the removal of a bucket if it is the last copy in a redundancy zone. There are a couple of issues with this approach. *Problem 1:* We may end up with two copies of the bucket in one zone in some cases With a slight tweak to the scenario fixed with GEODE-9554 we can end up never getting out of the situation where we have two copies of a bucket in the same zone. Steps: 1. Start two redundancy zones A and B with two members each. Bucket 0 is on member A1 and B1. 2. Shutdown member A1. 3. Rebalance - this will create bucket 0 on A2. 4. Shutdown B1. Revoke it's disk store and delete the data 5. Startup A1 - it will recover bucket 0. 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that situation. *Problem 2:* We may never delete extra copies of a bucket The fix for GEODE-9554 introduces a new problem if we have more than 2 redundancy zones Steps 1. Start three redundancy zones A,B,C with two members each. Bucket 0 is on A1 and B1> 2. Shutdown A1 3. Rebalance - this will create Bucket 0 on C1 4. Startup A1 - this will recreate bucket 0 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. I think the overall fix is probably to do something different than prevent removing the last copy of a bucket from a redundancy zone. Instead, I think we should do something like this: 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* buckets that have two copies in the same zone, as well as any buckets that are actually over redundancy. 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra copies of a bucket in the same zone first> 3. Back out the changes for GEODE-9554 and let the last copy be deleted from a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9815) Recovering persistent members can result in extra copies of a bucket or two copies int the same redundancy zone
[ https://issues.apache.org/jira/browse/GEODE-9815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9815: - Labels: needsTriage (was: ) > Recovering persistent members can result in extra copies of a bucket or two > copies int the same redundancy zone > --- > > Key: GEODE-9815 > URL: https://issues.apache.org/jira/browse/GEODE-9815 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.15.0 >Reporter: Dan Smith >Priority: Major > Labels: needsTriage > > The fix in GEODE-9554 is incomplete for some cases, and it also introduces a > new issue when removing buckets that are over redundancy. > GEODE-9554 and these new issues are all related to using redundancy zones and > having persistent members. > With persistence, when we start up a member with persisted buckets, we always > recover the persisted buckets on startup, regardless of whether redundancy is > already met or what zone the existing buckets are on. This is necessary to > ensure that we can recover all colocated buckets that might be persisted on > the member. > Because recovering these persistent buckets may cause us to go over > redundancy, after we recover from disk, we run a "restore redundancy" task > that actually removes copies of buckets that are over redundancy. > GEODE-9554 addressed one case where we end up removing the last copy of a > bucket from one redundancy zone while leaving two copies in another > redundancy zone. It did so by disallowing the removal of a bucket if it is > the last copy in a redundancy zone. > There are a couple of issues with this approach. > *Problem 1:* We may end up with two copies of the bucket in one zone in some > cases > With a slight tweak to the scenario fixed with GEODE-9554 we can end up never > getting out of the situation where we have two copies of a bucket in the same > zone. > Steps: > 1. Start two redundancy zones A and B with two members each. Bucket 0 is on > member A1 and B1. > 2. Shutdown member A1. > 3. Rebalance - this will create bucket 0 on A2. > 4. Shutdown B1. Revoke it's disk store and delete the data > 5. Startup A1 - it will recover bucket 0. > 6. At this point, bucket 0 is on A1 and A2, and nothing will resolve that > situation. > *Problem 2:* We may never delete extra copies of a bucket > The fix for GEODE-9554 introduces a new problem if we have more than 2 > redundancy zones > Steps > 1. Start three redundancy zones A,B,C with two members each. Bucket 0 is on > A1 and B1> > 2. Shutdown A1 > 3. Rebalance - this will create Bucket 0 on C1 > 4. Startup A1 - this will recreate bucket 0 > 5. Now we have bucket 0 on A1, B1, and C1. Nothing will remove the extra copy. > I think the overall fix is probably to do something different than prevent > removing the last copy of a bucket from a redundancy zone. Instead, I think > we should do something like this: > 1. Change PartitionRegionLoadModel.getOverRedundancyBuckets to return *any* > buckets that have two copies in the same zone, as well as any buckets that > are actually over redundancy. > 2. Change PartitionRegionLoadModel.findBestRemove to always remove extra > copies of a bucket in the same zone first> > 3. Back out the changes for GEODE-9554 and let the last copy be deleted from > a zone. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9449) remove 'b' prefix from constants
[ https://issues.apache.org/jira/browse/GEODE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donal Evans updated GEODE-9449: --- Affects Version/s: 1.15.0 > remove 'b' prefix from constants > > > Key: GEODE-9449 > URL: https://issues.apache.org/jira/browse/GEODE-9449 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Minor > Labels: pull-request-available > > I number of constants in the redis packages have a 'b' prefix on their name. > This might have been a use of Hungarian notation but that is not clear. The > convention for constant names in geode is all upper case with underscore > between words. So the 'b' prefix should be removed. See StringBytesGlossary > for the location of many of these constants. Most of the constants in > StringBytesGlossary contains bytes, one or more, but if a few of the > constants in it are actually String instances. Consider renaming them to have > _STRING suffix or moving them to another class like StringGlossary. > The byte array constants in this class are marked with the MakeImmutable > annotation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9449) remove 'b' prefix from constants
[ https://issues.apache.org/jira/browse/GEODE-9449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9449: -- Labels: pull-request-available (was: ) > remove 'b' prefix from constants > > > Key: GEODE-9449 > URL: https://issues.apache.org/jira/browse/GEODE-9449 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Darrel Schneider >Priority: Minor > Labels: pull-request-available > > I number of constants in the redis packages have a 'b' prefix on their name. > This might have been a use of Hungarian notation but that is not clear. The > convention for constant names in geode is all upper case with underscore > between words. So the 'b' prefix should be removed. See StringBytesGlossary > for the location of many of these constants. Most of the constants in > StringBytesGlossary contains bytes, one or more, but if a few of the > constants in it are actually String instances. Consider renaming them to have > _STRING suffix or moving them to another class like StringGlossary. > The byte array constants in this class are marked with the MakeImmutable > annotation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9803) CI Failure: AuthExpirationDUnitTest > registeredInterest_slowReAuth_policyDefault fails after user is expired
[
https://issues.apache.org/jira/browse/GEODE-9803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9803:
--
Labels: GeodeOperationAPI flaky needsTriage pull-request-available (was:
GeodeOperationAPI flaky needsTriage)
> CI Failure: AuthExpirationDUnitTest >
> registeredInterest_slowReAuth_policyDefault fails after user is expired
> -
>
> Key: GEODE-9803
> URL: https://issues.apache.org/jira/browse/GEODE-9803
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Jinmei Liao
>Priority: Major
> Labels: GeodeOperationAPI, flaky, needsTriage,
> pull-request-available
> Fix For: 1.15.0
>
>
> Originally seen in the distributed mass test run:
> {noformat}
> > Task :geode-core:distributedTest
> AuthExpirationDUnitTest > registeredInterest_slowReAuth_policyDefault FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.AuthExpirationDUnitTest$$Lambda$580/141775835.run
> in VM 0 running on Host
> heavy-lifter-2a24cff8-0d64-55e0-9585-2d6391f92533.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.test.junit.rules.VMProvider.invoke(VMProvider.java:96)
> at
> org.apache.geode.security.AuthExpirationDUnitTest.registeredInterest_slowReAuth_policyDefault(AuthExpirationDUnitTest.java:156)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.security.AuthExpirationDUnitTest that uses
> org.apache.geode.cache.Region
> Expected size: 100 but was: 0 in:
> [] 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.security.AuthExpirationDUnitTest.lambda$registeredInterest_slowReAuth_policyDefault$bb17a952$2(AuthExpirationDUnitTest.java:158)
> Caused by:
> java.lang.AssertionError:
> Expected size: 100 but was: 0 in:
> []
> at
> org.apache.geode.security.AuthExpirationDUnitTest.lambda$null$3(AuthExpirationDUnitTest.java:159)
> 8334 tests completed, 1 failed, 414 skipped
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0646/test-results/distributedTest/1636236082/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0646/test-artifacts/1636236082/distributedtestfiles-openjdk8-1.15.0-build.0646.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9738) CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable failed with DistributedSystemDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9738:
Attachment: GEODE-9738-short.log.all
> CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable
> failed with DistributedSystemDisconnectedException
> ---
>
> Key: GEODE-9738
> URL: https://issues.apache.org/jira/browse/GEODE-9738
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Bill Burcham
>Priority: Major
> Labels: needsTriage
> Attachments: GEODE-9738-short.log.all, controller.log, locator.log,
> vm0.log, vm1.log, vm2.log, vm3.log
>
>
> {noformat}
> RollingUpgradeRollServersOnReplicatedRegion_dataserializable >
> testRollServersOnReplicatedRegion_dataserializable[from_v1.13.4] 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 685[fatal
> 2021/10/14 00:24:14.739 UTC tid=115] Uncaught exception
> in thread Thread[FederatingManager6,5,RMI Runtime]
> org.apache.geode.management.ManagementException:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:486)
> at
> org.apache.geode.management.internal.FederatingManager$AddMemberTask.call(FederatingManager.java:596)
> at
> org.apache.geode.management.internal.FederatingManager.lambda$addMember$1(FederatingManager.java:199)
> 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)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2885)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5212)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:121)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1164)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:78)
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:429)
> ... 5 more
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:420)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:436)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481)
> at jdk.internal.reflect.GeneratedMethodAccessor11.invoke(Unknown
> Source)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
>
[jira] [Comment Edited] (GEODE-9738) CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable failed with DistributedSystemDisconnectedException
[
https://issues.apache.org/jira/browse/GEODE-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17441878#comment-17441878
]
Bill Burcham edited comment on GEODE-9738 at 11/16/21, 10:55 PM:
-
The logs in the failing test run (previous comment) are all interleaved in the
"standard output" section of the failing test. I have attached the individual
logs to the ticket, so we can analyze them.
The attached logs (controller.log, locator.log, vm\{0-3}.log) each contain
content for multiple tests. I've attached the stdout for just the test of
interest as GEODE-9738-short.log.all. That needs to be split so we can see a
more focused view of the various logs.
was (Author: bburcham):
The logs in the failing test run (previous comment) are all interleaved in the
"standard output" section of the failing test. I have attached the individual
logs to the ticket, so we can analyze them.
> CI failure: RollingUpgradeRollServersOnReplicatedRegion_dataserializable
> failed with DistributedSystemDisconnectedException
> ---
>
> Key: GEODE-9738
> URL: https://issues.apache.org/jira/browse/GEODE-9738
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Bill Burcham
>Priority: Major
> Labels: needsTriage
> Attachments: GEODE-9738-short.log.all, controller.log, locator.log,
> vm0.log, vm1.log, vm2.log, vm3.log
>
>
> {noformat}
> RollingUpgradeRollServersOnReplicatedRegion_dataserializable >
> testRollServersOnReplicatedRegion_dataserializable[from_v1.13.4] 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 685[fatal
> 2021/10/14 00:24:14.739 UTC tid=115] Uncaught exception
> in thread Thread[FederatingManager6,5,RMI Runtime]
> org.apache.geode.management.ManagementException:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:486)
> at
> org.apache.geode.management.internal.FederatingManager$AddMemberTask.call(FederatingManager.java:596)
> at
> org.apache.geode.management.internal.FederatingManager.lambda$addMember$1(FederatingManager.java:199)
> 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)
> Caused by:
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> Distribution manager on
> heavy-lifter-10ae5f9d-2528-5e02-b707-d968eb54d50a(vm2:580278:locator):54751
> started at Thu Oct 14 00:23:52 UTC 2021: Message distribution has terminated
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2885)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5212)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.internal.cache.CreateRegionProcessor.initializeRegion(CreateRegionProcessor.java:121)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1164)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:78)
> at
> org.apache.geode.management.internal.FederatingManager.addMemberArtifacts(FederatingManager.java:429)
> ... 5 more
> at org.junit.Assert.fail(Assert.java:89)
> at
> org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:420)
> at
>
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9811: -- Component/s: security > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core, security >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444841#comment-17444841
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r750706205
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -39,19 +42,56 @@ namespace {
using apache::geode::client::binary_semaphore;
using apache::geode::client::Cache;
using apache::geode::client::CacheableInt16;
+using apache::geode::client::CacheableInt32;
using apache::geode::client::CacheableKey;
using apache::geode::client::CacheableString;
using apache::geode::client::CacheFactory;
using apache::geode::client::CacheListenerMock;
+using apache::geode::client::EntryEvent;
using apache::geode::client::IllegalStateException;
using apache::geode::client::Region;
+using apache::geode::client::RegionEvent;
using apache::geode::client::RegionShortcut;
+using apache::geode::client::CacheListener;
using ::testing::_;
using ::testing::DoAll;
using ::testing::InvokeWithoutArgs;
using ::testing::Return;
+const int NUMKEYS = 100;
+
+class MyCacheListener : public CacheListener {
Review comment:
You agreed a real CacheListener with count_down latches was appropriate.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9804) Both registerAllKeys and registerRegex always fetch initial entries.
[
https://issues.apache.org/jira/browse/GEODE-9804?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444842#comment-17444842
]
ASF GitHub Bot commented on GEODE-9804:
---
mmartell commented on a change in pull request #894:
URL: https://github.com/apache/geode-native/pull/894#discussion_r750706390
##
File path: cppcache/integration/test/RegisterKeysTest.cpp
##
@@ -575,4 +615,233 @@ TEST(RegisterKeysTest, RegisterAnyWithProxyRegion) {
cache.close();
}
+apache::geode::client::Cache createCache() {
+ return apache::geode::client::CacheFactory()
+ .set("log-level", "none")
+ .set("statistic-sampling-enabled", "false")
+ .create();
+}
+
+std::shared_ptr createPool(
+Cluster& cluster, apache::geode::client::Cache& cache) {
+ auto poolFactory = cache.getPoolManager().createFactory();
+ cluster.applyLocators(poolFactory);
+ poolFactory.setSubscriptionEnabled(true); // Per the customer.
+ return poolFactory.create("default");
+}
+
+std::shared_ptr setupRegion(
+apache::geode::client::Cache& cache,
+const std::shared_ptr& pool) {
+ auto region =
+ cache
+ .createRegionFactory(apache::geode::client::RegionShortcut::
+ CACHING_PROXY) // Per the customer.
+ .setPoolName(pool->getName())
+ .create("region");
+
+ return region;
+}
+
+TEST(RegisterKeysTest, DontReceiveValues) {
+ Cluster cluster{LocatorCount{1}, ServerCount{1}};
+
+ cluster.start();
+
+ cluster.getGfsh()
+ .create()
+ .region()
+ .withName("region")
+ .withType("PARTITION")
+ .execute();
+
+ auto cache1 = createCache();
+ auto pool1 = createPool(cluster, cache1);
+ auto region1 = setupRegion(cache1, pool1);
+ auto attrMutator = region1->getAttributesMutator();
+ auto listener = std::make_shared();
+ attrMutator->setCacheListener(listener);
+
+ auto cache2 = createCache();
+ auto pool2 = createPool(cluster, cache2);
+ auto region2 = setupRegion(cache2, pool2);
+
+ for (int i = 0; i < NUMKEYS; i++) {
+region2->put(apache::geode::client::CacheableInt32::create(i),
Review comment:
Good catch. Done.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Both registerAllKeys and registerRegex always fetch initial entries.
>
>
> Key: GEODE-9804
> URL: https://issues.apache.org/jira/browse/GEODE-9804
> Project: Geode
> Issue Type: Bug
>Reporter: Jacob Barrett
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> A inconsistency and bug in how the two regex interest methods configure the
> initial interest policy results in the both registerAllKeys and registerRegex
> fetching all initial entries despite the boolean parameter to get initial
> entries. Furthermore the misconfiguration results in none of the entries
> actually getting sent to the cache listener. The result is unnecessarily long
> registration times, network traffic and load on the servers. On servers with
> say millions of keys this can result in long GC pauses to unintentionally
> iterate over all those keys.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9814) Add an example of geode-for-redis to the geode examples project
Dan Smith created GEODE-9814: Summary: Add an example of geode-for-redis to the geode examples project Key: GEODE-9814 URL: https://issues.apache.org/jira/browse/GEODE-9814 Project: Geode Issue Type: Improvement Components: redis Reporter: Dan Smith h4. Add an example to the geode-examples project demonstrating how to turn on and use geode-for-redis. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9813) Move geode-for-redis properties to the geode-for-redis module
[ https://issues.apache.org/jira/browse/GEODE-9813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-9813: - Component/s: redis > Move geode-for-redis properties to the geode-for-redis module > - > > Key: GEODE-9813 > URL: https://issues.apache.org/jira/browse/GEODE-9813 > Project: Geode > Issue Type: Improvement > Components: redis >Reporter: Dan Smith >Priority: Major > > The goal is that geode-core should have no references to geode-for-redis > gemfire properties. > This probably involves these steps: > * Change geode-core to support dynamically discovering modules that define > new gemfire properties, perhaps using a service loader or other mechanism. > Update the validation logic of gemfire properties to include these > dynamically discovered properties. > * Move the definition of the geode-for-redis properties to the > geode-for-redis module. This includes moving the public > ConfigurationProperties constants to some new public interface in the > geode-for-redis module. > We should consider deprecating and moving properties for other modules as > well - for example the memcached properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9813) Move geode-for-redis properties to the geode-for-redis module
Dan Smith created GEODE-9813: Summary: Move geode-for-redis properties to the geode-for-redis module Key: GEODE-9813 URL: https://issues.apache.org/jira/browse/GEODE-9813 Project: Geode Issue Type: Improvement Reporter: Dan Smith The goal is that geode-core should have no references to geode-for-redis gemfire properties. This probably involves these steps: * Change geode-core to support dynamically discovering modules that define new gemfire properties, perhaps using a service loader or other mechanism. Update the validation logic of gemfire properties to include these dynamically discovered properties. * Move the definition of the geode-for-redis properties to the geode-for-redis module. This includes moving the public ConfigurationProperties constants to some new public interface in the geode-for-redis module. We should consider deprecating and moving properties for other modules as well - for example the memcached properties. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9811: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9812) Kill multiple Radish servers expecting operations to continue
[ https://issues.apache.org/jira/browse/GEODE-9812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9812: -- Labels: pull-request-available (was: ) > Kill multiple Radish servers expecting operations to continue > - > > Key: GEODE-9812 > URL: https://issues.apache.org/jira/browse/GEODE-9812 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > Kill more than one server and expect the distributed system to recover. Data > loss is expected. The motivation behind this test is to ensure that, in a > situation where both the primary and secondary buckets are not available, > Redis clients are able to continue doing ops without getting stuck or hitting > loops of MOVED responses etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9812) Kill multiple Radish servers expecting operations to continue
Jens Deppe created GEODE-9812: - Summary: Kill multiple Radish servers expecting operations to continue Key: GEODE-9812 URL: https://issues.apache.org/jira/browse/GEODE-9812 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe Kill more than one server and expect the distributed system to recover. Data loss is expected. The motivation behind this test is to ensure that, in a situation where both the primary and secondary buckets are not available, Redis clients are able to continue doing ops without getting stuck or hitting loops of MOVED responses etc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9811: -- Labels: GeodeOperationAPI (was: ) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior reassigned GEODE-9811: - Assignee: Joris Melchior > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Assignee: Joris Melchior >Priority: Major > Labels: GeodeOperationAPI > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joris Melchior updated GEODE-9811: -- Labels: (was: needsTriage) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Priority: Major > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
Joris Melchior created GEODE-9811: - Summary: When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException Key: GEODE-9811 URL: https://issues.apache.org/jira/browse/GEODE-9811 Project: Geode Issue Type: Bug Components: core Affects Versions: 1.14.0 Reporter: Joris Melchior Due to the sequence of events occurring when a server is shutting down it's possible for some transactions to not be able to get the security manager while performing an operation. Currently the operation fails without retry while the correct behaviour would be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException
[ https://issues.apache.org/jira/browse/GEODE-9811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9811: - Labels: needsTriage (was: ) > When a node is stopped using nice_exit or its cache is closing, client may > fail due to UnavailableSecurityManagerException > -- > > Key: GEODE-9811 > URL: https://issues.apache.org/jira/browse/GEODE-9811 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Joris Melchior >Priority: Major > Labels: needsTriage > > Due to the sequence of events occurring when a server is shutting down it's > possible for some transactions to not be able to get the security manager > while performing an operation. > Currently the operation fails without retry while the correct behaviour would > be to try and retry the operation at least once on another member. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-6645) CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest > testDataStoreEntryCount FAILED
[
https://issues.apache.org/jira/browse/GEODE-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444715#comment-17444715
]
Geode Integration commented on GEODE-6645:
--
Seen on support/1.12 in [distributed-test-openjdk11
#2|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/distributed-test-openjdk11/builds/2]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0311/test-results/distributedTest/1637062094/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.6-build.0311/test-artifacts/1637062094/distributedtestfiles-openjdk11-1.12.6-build.0311.tgz].
> CI: org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
>
>
> Key: GEODE-6645
> URL: https://issues.apache.org/jira/browse/GEODE-6645
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.10.0
>Reporter: Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI, GeodeOperationAPI
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/617
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest >
> testDataStoreEntryCount FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]L> but was:<[2]L>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.validateEntryCount(PartitionedRegionStatsDUnitTest.java:267)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.lambda$testDataStoreEntryCount$bb17a952$18(PartitionedRegionStatsDUnitTest.java:198)
> {noformat}
> Artifacts are available here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-results/distributedTest/1555097363/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0176/test-artifacts/1555097363/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0176.tgz
> {noformat}
> Looking at this test, it goes through several phases of entry creation,
> destroy, destroy + put and GII (after adding a new member) for a partitioned
> region with redundantCopies=2. After adding the new member and forcing
> tombstone expiration, the newly created vm ends up with 1 less entry than
> expected (but the original two vms appear to have the expected number of
> entries (3)).
> Full stack
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest$$Lambda$172/0x00084024dc40.run
> in VM 2 running on Host 1ee860aba5ac with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PartitionedRegionStatsDUnitTest.testDataStoreEntryCount(PartitionedRegionStatsDUnitTest.java:198)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
>
[jira] [Updated] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
[
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9810:
-
Labels: needsTriage (was: )
> 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
>Priority: Major
> Labels: needsTriage
>
> 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] [Commented] (GEODE-9810) CI: NativeRedisClusterTest testEachProxyReturnsExposedPorts failed
[
https://issues.apache.org/jira/browse/GEODE-9810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444714#comment-17444714
]
Geode Integration commented on GEODE-9810:
--
Seen in [acceptance-test-openjdk8
#9|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/9]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/]
or download
[artifacts|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].
> 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
>Priority: Major
> Labels: needsTriage
>
> 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] [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] [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=17444709#comment-17444709
]
Geode Integration commented on GEODE-9428:
--
Seen in [acceptance-test-openjdk8
#8|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/8]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0661/test-results/acceptanceTest/1637025337/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0661/test-artifacts/1637025337/acceptancetestfiles-openjdk8-1.15.0-build.0661.tgz].
> 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
[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] [Commented] (GEODE-9196) CI: NativeRedisClusterTest.classMethod failed
[ https://issues.apache.org/jira/browse/GEODE-9196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444707#comment-17444707 ] Geode Integration commented on GEODE-9196: -- Seen in [acceptance-test-openjdk8 #9|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/acceptance-test-openjdk8/builds/9] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0662/test-results/acceptanceTest/1637046056/] or download [artifacts|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]. > 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 >Assignee: Jens Deppe >Priority: Major > > 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 >
[jira] [Commented] (GEODE-8191) MemberMXBeanDistributedTest.testBucketCount fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-8191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444705#comment-17444705
]
Geode Integration commented on GEODE-8191:
--
Seen in [distributed-test-openjdk8
#10|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/10]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0663/test-results/distributedTest/1637080725/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0663/test-artifacts/1637080725/distributedtestfiles-openjdk8-1.15.0-build.0663.tgz].
> MemberMXBeanDistributedTest.testBucketCount fails intermittently
>
>
> Key: GEODE-8191
> URL: https://issues.apache.org/jira/browse/GEODE-8191
> Project: Geode
> Issue Type: Bug
> Components: jmx, tests
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Kirk Lund
>Assignee: Mario Ivanac
>Priority: Major
> Labels: flaky, pull-request-available
>
> This appears to be a flaky test related to GEODE-7963 which was resolved by
> Mario Ivanac so I've assigned the ticket to him.
> {noformat}
> org.apache.geode.management.MemberMXBeanDistributedTest > testBucketCount
> FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.MemberMXBeanDistributedTest Expected bucket count
> is 4000, and actual count is 3750 expected:<3750> but was:<4000> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.testBucketCount(MemberMXBeanDistributedTest.java:102)
> Caused by:
> java.lang.AssertionError: Expected bucket count is 4000, and actual
> count is 3750 expected:<3750> but was:<4000>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at
> org.apache.geode.management.MemberMXBeanDistributedTest.lambda$testBucketCount$1(MemberMXBeanDistributedTest.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9090) Suspect Strings in Logs DeploymentManagementRedployDUnitTest > redeployJarsWithNewVersionsOfFunctions
[
https://issues.apache.org/jira/browse/GEODE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17444560#comment-17444560
]
ASF subversion and git services commented on GEODE-9090:
Commit 0ac9c8a044cdab510785c4015e4843b4d94eb75c in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ac9c8a ]
GEODE-9090: Do not log non-printable characters when debug logging from
ManagementLoggingFilter (#7110)
- This can cause spurious DUnit suspect logging failures.
> Suspect Strings in Logs DeploymentManagementRedployDUnitTest >
> redeployJarsWithNewVersionsOfFunctions
> -
>
> Key: GEODE-9090
> URL: https://issues.apache.org/jira/browse/GEODE-9090
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Suspect strings in logs in this CI run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/107:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctions 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 691
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u)\u\u0004\uDeployCommandRedeployDUnitFunctionA.class\u\u~~n~~@\u0010~~?~~IhChh~~:
> ~~Bp+B~~\u0012E
> EP5P$nJ~~r~~h~~F~~g~~\u\u0017P9~~\u<\u0014b~~qUp~~H\u000fw~~~y\u000f\uO~~ `~~?~~2G\u0006~~%%~~^
> O~~C
>
> i\u0008?~~.w~~Y~~\u000c~~My;~~K\u0006~~\u001c
>
> dl~~\u001a8~~\u0003u1~~OZB#~~mandRedeployDUnitFunctionA.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\u[\u\u\uj\u0002\u\u\u\u
> --uWbis1NkO9dSY3pUDEYgZgkx4bh2w52
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 710
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u:\u\u0004\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\u~~RMo~~@\u0010}~~/\u001b!$\u0016Z'~~j!z+B*~~"~~"~~\u001a(\u0012\u001b9vd~~Q~~7q~~\u000b~~\u001c~~\u0001~~(~~*~~\u0007R~~4~~;\u0007~~=~~\u000c]G\u001b\u001d\u001dw~~X\u00064aC~~\u0026C\u000c~~z~~P~~\u000c~
>
> ~~\u000cd:\u0016~~+>~~Is~~G"N|~~A~~2h~~T8~~"~~#k\u0018Fg~~9\u0011~~'(d~~\u001cb\u000fQ2\u000c~~aOSU=~~\u000c-~~;~~y#\u0015~~gh~~3%~~\u0018~~H~~y*2~vC?x~~\u0016IN~~(L"G\u000cdZ~~u(f~\uS\u001e~~GzL\u0018~~k~~o~~\u0001~~\u0018~~c\u0011~~d|~~a~~.\u001c~~L4q~~ao
>
> wx"\u001c~~y{NR\u0019v~~F?3\u0008\\\u00111~~D~@\\~~\\\u0001Ny\u0017h~~\u001a\u0016:\u000e~~5~~_~~n~~
>
> I~t3~~o`_p~~d-S~~H.`1sh[\u0026~~\u001c~~C~~\u000es~~\u0012C~~|~~J
> \u0017~~w~~44~~/7\u000b
> ~~H~~.\u0017R.\u0016~~Ari\u000e~~V\u0012/_+j)\u0007 X~~
>
>
[jira] [Resolved] (GEODE-9090) Suspect Strings in Logs DeploymentManagementRedployDUnitTest > redeployJarsWithNewVersionsOfFunctions
[
https://issues.apache.org/jira/browse/GEODE-9090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9090.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Suspect Strings in Logs DeploymentManagementRedployDUnitTest >
> redeployJarsWithNewVersionsOfFunctions
> -
>
> Key: GEODE-9090
> URL: https://issues.apache.org/jira/browse/GEODE-9090
> Project: Geode
> Issue Type: Task
> Components: management
>Reporter: Bill Burcham
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Suspect strings in logs in this CI run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/107:
> {code:java}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > redeployJarsWithNewVersionsOfFunctions 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 691
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u)\u\u0004\uDeployCommandRedeployDUnitFunctionA.class\u\u~~n~~@\u0010~~?~~IhChh~~:
> ~~Bp+B~~\u0012E
> EP5P$nJ~~r~~h~~F~~g~~\u\u0017P9~~\u<\u0014b~~qUp~~H\u000fw~~~y\u000f\uO~~ `~~?~~2G\u0006~~%%~~^
> O~~C
>
> i\u0008?~~.w~~Y~~\u000c~~My;~~K\u0006~~\u001c
>
> dl~~\u001a8~~\u0003u1~~OZB#~~mandRedeployDUnitFunctionA.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\u[\u\u\uj\u0002\u\u\u\u
> --uWbis1NkO9dSY3pUDEYgZgkx4bh2w52
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 710
>
> PK\u0003\u0004\u0014\u\u0008\u0008\u0008\u{4}R\u\u\u\u\u\u\u\u\u\u\u\u:\u\u0004\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\u~~RMo~~@\u0010}~~/\u001b!$\u0016Z'~~j!z+B*~~"~~"~~\u001a(\u0012\u001b9vd~~Q~~7q~~\u000b~~\u001c~~\u0001~~(~~*~~\u0007R~~4~~;\u0007~~=~~\u000c]G\u001b\u001d\u001dw~~X\u00064aC~~\u0026C\u000c~~z~~P~~\u000c~
>
> ~~\u000cd:\u0016~~+>~~Is~~G"N|~~A~~2h~~T8~~"~~#k\u0018Fg~~9\u0011~~'(d~~\u001cb\u000fQ2\u000c~~aOSU=~~\u000c-~~;~~y#\u0015~~gh~~3%~~\u0018~~H~~y*2~vC?x~~\u0016IN~~(L"G\u000cdZ~~u(f~\uS\u001e~~GzL\u0018~~k~~o~~\u0001~~\u0018~~c\u0011~~d|~~a~~.\u001c~~L4q~~ao
>
> wx"\u001c~~y{NR\u0019v~~F?3\u0008\\\u00111~~D~@\\~~\\\u0001Ny\u0017h~~\u001a\u0016:\u000e~~5~~_~~n~~
>
> I~t3~~o`_p~~d-S~~H.`1sh[\u0026~~\u001c~~C~~\u000es~~\u0012C~~|~~J
> \u0017~~w~~44~~/7\u000b
> ~~H~~.\u0017R.\u0016~~Ari\u000e~~V\u0012/_+j)\u0007 X~~
>
> PK\u0007\u0008~~w7\u0001\u\u\u0001\u0004\u\uPK\u0001\u0002\u0014\u\u0014\u\u0008\u0008\u0008\u{4}R~~w7\u0001\u\u\u0001\u0004\u\u:\u\u0004\u\u\u\u\u\u\u\u\u\u\u\u\u\u\ujddunit/function/DeployCommandRedeployDUnitFunctionB.class\u\uPK\u0005\u0006\u\u\u\u\u0001\u\u0001\ul\u\u\uZ\u0002\u\u\u\u
> --XADbzFelszjYv8QsixUwkKt2kmAJrXT6W
> Content-Disposition: form-data; name="config"
> Content-Type: application/json
> ---
> Found suspect string in 'dunit_suspect-vm0.log' at line 729
>
>
[jira] [Updated] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-9809: Description: When performing consecutive create/destroy colocated persistent partitioned regions, memory leak is observed. In our test, in cluster with 50 servers, we have leader persisted partitioned region with more than 1000 buckets, and colocated 2 persisted regions. If we consecutively create and destroy child regions, memory leak is observed. was:When performing consecutive create/destroy colocated persistent partitioned regions, memory leak is observed. In our test, in cluster with 50 servers, memory leak is observed in previous scenario. > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: memcached >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. > In our test, in cluster with 50 servers, we have leader persisted partitioned > region with more than 1000 buckets, and colocated 2 persisted regions. If we > consecutively create and destroy child regions, memory leak is observed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9809: -- Labels: needsTriage pull-request-available (was: needsTriage) > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: memcached >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage, pull-request-available > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. In our test, in cluster with 50 servers, > memory leak is observed in previous scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-9809: --- Assignee: Mario Ivanac > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: memcached >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. In our test, in cluster with 50 servers, > memory leak is observed in previous scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9809) Memory leak in PersistentBucketRecoverer
[ https://issues.apache.org/jira/browse/GEODE-9809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9809: - Labels: needsTriage (was: ) > Memory leak in PersistentBucketRecoverer > > > Key: GEODE-9809 > URL: https://issues.apache.org/jira/browse/GEODE-9809 > Project: Geode > Issue Type: Bug > Components: memcached >Affects Versions: 1.14.0 >Reporter: Mario Ivanac >Priority: Major > Labels: needsTriage > > When performing consecutive create/destroy colocated persistent partitioned > regions, memory leak is observed. In our test, in cluster with 50 servers, > memory leak is observed in previous scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9809) Memory leak in PersistentBucketRecoverer
Mario Ivanac created GEODE-9809: --- Summary: Memory leak in PersistentBucketRecoverer Key: GEODE-9809 URL: https://issues.apache.org/jira/browse/GEODE-9809 Project: Geode Issue Type: Bug Components: memcached Affects Versions: 1.14.0 Reporter: Mario Ivanac When performing consecutive create/destroy colocated persistent partitioned regions, memory leak is observed. In our test, in cluster with 50 servers, memory leak is observed in previous scenario. -- This message was sent by Atlassian Jira (v8.20.1#820001)
