[jira] [Created] (GEODE-7332) Add OQL Aggregates link in docs
Karen Smoler Miller created GEODE-7332: -- Summary: Add OQL Aggregates link in docs Key: GEODE-7332 URL: https://issues.apache.org/jira/browse/GEODE-7332 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller Small change, but useful. File developing/querying_basics/what_is_a_query_string.html has a list of useful query string building blocks. Add a link to the descriptions of the OQL aggregates to the list. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7291) Cluster and Member micrometer common tags should not be used with empty values
[
https://issues.apache.org/jira/browse/GEODE-7291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7291.
--
Fix Version/s: 1.11.0
Resolution: Fixed
> Cluster and Member micrometer common tags should not be used with empty values
> --
>
> Key: GEODE-7291
> URL: https://issues.apache.org/jira/browse/GEODE-7291
> Project: Geode
> Issue Type: Improvement
> Components: statistics
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Creating tags without values is something that Micrometer recommends against
> doing. With our common tags we need to consider the implications of adding
> them outside of a server/locator member of a cluster.
> {code}
> Given I create a cache without a member name
> When I add a meterregistry to that cache
> Then I should not see the member common tag:
> - member
> And I should see the following common tags:
> - cluster
> - host
> - member_type
> {code}
> {code}
> Given I create a clientcache through Java
> When I add a meterregistry to that cache
> Then I should not see the following common tags:
> - cluster
> And I should see the following common tags:
> - host
> - member
> - member_type
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7327) Collapse InternalDistributedMember, NetMember, GMSMemberAdapter, and GMSMember
[ https://issues.apache.org/jira/browse/GEODE-7327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt updated GEODE-7327: -- Issue Type: Improvement (was: Bug) > Collapse InternalDistributedMember, NetMember, GMSMemberAdapter, and GMSMember > -- > > Key: GEODE-7327 > URL: https://issues.apache.org/jira/browse/GEODE-7327 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bill Burcham >Priority: Major > Fix For: 1.11.0 > > > All of these classes contain member id information that is required by > geode-core (durable client attributes). So there is not really any reason to > have so many different nested classes and abstractions. Turn these all into a > single object. > One important benefit of this work is that it will simplify our interprocess > communication. For instance, we won't be sending around GMSMember any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7312) modify the ThreadMonitor to print the stack of a blocking thread
[ https://issues.apache.org/jira/browse/GEODE-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956495#comment-16956495 ] ASF subversion and git services commented on GEODE-7312: Commit 59459c218ce9eb78f527e651867aa6f260eb15ac in geode's branch refs/heads/develop from Bruce Schuchardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=59459c2 ] GEODE-7312: modify the ThreadMonitor to print the stack of a blocking thread Log a thread trace for a thread that's blocking a "stuck" thread. This will help a lot when a user experiences hung operations. Prior to this change we needed to request thread dumps for servers and that was usually not possible to obtain because the servers had already been terminated & restarted. This change puts the relevant thread dumps in the server's log file, which is much easier for folks to gather after the fact. > modify the ThreadMonitor to print the stack of a blocking thread > > > Key: GEODE-7312 > URL: https://issues.apache.org/jira/browse/GEODE-7312 > Project: Geode > Issue Type: Improvement > Components: messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: low-hanging-fruit, newbie > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Our thread monitor does a good job of telling us about stuck threads. If a > thread is stuck trying to synchronize on an object the monitor even tells us > the name of that thread. We should enhance this to give us a stack dump of > the thread that owns the lock. Sometimes this is a thread that's not > monitored by ThreadMonitor so we don't know what it's doing unless someone > takes a thread dump of the whole process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7312) modify the ThreadMonitor to print the stack of a blocking thread
[ https://issues.apache.org/jira/browse/GEODE-7312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt resolved GEODE-7312. --- Fix Version/s: 1.11.0 Resolution: Fixed > modify the ThreadMonitor to print the stack of a blocking thread > > > Key: GEODE-7312 > URL: https://issues.apache.org/jira/browse/GEODE-7312 > Project: Geode > Issue Type: Improvement > Components: messaging >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Labels: low-hanging-fruit, newbie > Fix For: 1.11.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Our thread monitor does a good job of telling us about stuck threads. If a > thread is stuck trying to synchronize on an object the monitor even tells us > the name of that thread. We should enhance this to give us a stack dump of > the thread that owns the lock. Sometimes this is a thread that's not > monitored by ThreadMonitor so we don't know what it's doing unless someone > takes a thread dump of the whole process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-7328.
--
Fix Version/s: 1.11.0
Resolution: Fixed
> CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.distributed.ServerLauncherTest >
> startRunsExceptionActionAfterStartupTasksError FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsExceptionActionAfterStartupTasksError(ServerLauncherTest.java:368)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startRunsCompletionActionAfterStartupTasksComplete FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsCompletionActionAfterStartupTasksComplete(ServerLauncherTest.java:346)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesControllableProcessFromBuilder FAILED java.lang.RuntimeException: An
> IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesControllableProcessFromBuilder(ServerLauncherTest.java:402)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesCacheProviderFromBuilder FAILED java.lang.RuntimeException: An IO
> error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesCacheProviderFromBuilder(ServerLauncherTest.java:385)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startCacheServerDoesNothingWhenCacheServerAlreadyExists FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
>
[jira] [Commented] (GEODE-7316) Race condition results in crash at shutdown
[ https://issues.apache.org/jira/browse/GEODE-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956490#comment-16956490 ] ASF subversion and git services commented on GEODE-7316: Commit 2c70be377941487a5ff45eccea04ef65a51dd61c in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=2c70be3 ] GEODE-7316: Fix nc shutdown crash (#539) > Race condition results in crash at shutdown > --- > > Key: GEODE-7316 > URL: https://issues.apache.org/jira/browse/GEODE-7316 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > > A race condition between the CacheImpl::close and the ThinClientPRMetadata > object that causes the crash because the CacheImpl pointer > ThinClientPRMetadata is trying to use has been deleted. > > We need a C++ test written to verify this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7322) generate wiki page of Cluster Management Service from Swagger page
[ https://issues.apache.org/jira/browse/GEODE-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956485#comment-16956485 ] Owen Nichols commented on GEODE-7322: - dup of GEODE-7205 > generate wiki page of Cluster Management Service from Swagger page > -- > > Key: GEODE-7322 > URL: https://issues.apache.org/jira/browse/GEODE-7322 > Project: Geode > Issue Type: Bug > Components: management, rest (admin) >Reporter: Gang Yan >Assignee: Owen Nichols >Priority: Major > > #WHY > we want to get the latest update of restapi, and update wiki page > automatically > #WHAT > find a programming way to update wiki page > And sync the latest update of Swagger to wiki > related: > GEODE-7205 : https://issues.apache.org/jira/browse/GEODE-7205 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7322) generate wiki page of Cluster Management Service from Swagger page
[ https://issues.apache.org/jira/browse/GEODE-7322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-7322: --- Assignee: Owen Nichols > generate wiki page of Cluster Management Service from Swagger page > -- > > Key: GEODE-7322 > URL: https://issues.apache.org/jira/browse/GEODE-7322 > Project: Geode > Issue Type: Bug > Components: management, rest (admin) >Reporter: Gang Yan >Assignee: Owen Nichols >Priority: Major > > #WHY > we want to get the latest update of restapi, and update wiki page > automatically > #WHAT > find a programming way to update wiki page > And sync the latest update of Swagger to wiki > related: > GEODE-7205 : https://issues.apache.org/jira/browse/GEODE-7205 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7205) sync wiki page of Cluster Management Service with Swagger page
[ https://issues.apache.org/jira/browse/GEODE-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols reassigned GEODE-7205: --- Assignee: Owen Nichols > sync wiki page of Cluster Management Service with Swagger page > -- > > Key: GEODE-7205 > URL: https://issues.apache.org/jira/browse/GEODE-7205 > Project: Geode > Issue Type: Improvement > Components: management, rest (admin) >Reporter: Gang Yan >Assignee: Owen Nichols >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > > #WHY > there are a lot of stuff need to sync-up from Swagger page to wiki, > Including but not limited to : > - class > - config --> configuration > - links > - group & groups > - experies > And we do not want to update the wiki page again and again, and also the more > we delivered , the more update we need to publish on wiki page, so we need to > find a way to generate wiki page from Swagger page in programming way. > #WHAT > there is a Swagger page and api-docs, everything is there, so we need to find > a way to parse the swagger page to generate Wiki page. > 1. find input > 2. find output format on wiki > 3. parse the input to output format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956475#comment-16956475
]
ASF subversion and git services commented on GEODE-7328:
Commit f506638b4cb06e3d5b48311eb4fe810aef48e3fa in geode's branch
refs/heads/develop from Kirk Lund
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f506638 ]
GEODE-7328: Prevent BindExceptions in ServerLauncherTest
Use disable-default-server to prevent binding to default port in unit
test.
> CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.distributed.ServerLauncherTest >
> startRunsExceptionActionAfterStartupTasksError FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsExceptionActionAfterStartupTasksError(ServerLauncherTest.java:368)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startRunsCompletionActionAfterStartupTasksComplete FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsCompletionActionAfterStartupTasksComplete(ServerLauncherTest.java:346)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesControllableProcessFromBuilder FAILED java.lang.RuntimeException: An
> IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesControllableProcessFromBuilder(ServerLauncherTest.java:402)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesCacheProviderFromBuilder FAILED java.lang.RuntimeException: An IO
> error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesCacheProviderFromBuilder(ServerLauncherTest.java:385)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startCacheServerDoesNothingWhenCacheServerAlreadyExists FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
>
[jira] [Assigned] (GEODE-7331) Improve docs on logging (with optional Log4j)
[ https://issues.apache.org/jira/browse/GEODE-7331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-7331: -- Assignee: Karen Smoler Miller > Improve docs on logging (with optional Log4j) > - > > Key: GEODE-7331 > URL: https://issues.apache.org/jira/browse/GEODE-7331 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > > Log4j is in its own module. Update the docs to reflect changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7331) Improve docs on logging (with optional Log4j)
Karen Smoler Miller created GEODE-7331: -- Summary: Improve docs on logging (with optional Log4j) Key: GEODE-7331 URL: https://issues.apache.org/jira/browse/GEODE-7331 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller Log4j is in its own module. Update the docs to reflect changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7330) CI Failure: RebalanceCommandDUnitTest > testWithTimeOutAndRegion FAILED
[
https://issues.apache.org/jira/browse/GEODE-7330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7330:
Assignee: Kirk Lund
> CI Failure: RebalanceCommandDUnitTest > testWithTimeOutAndRegion FAILED
> ---
>
> Key: GEODE-7330
> URL: https://issues.apache.org/jira/browse/GEODE-7330
> Project: Geode
> Issue Type: Test
> Components: jmx
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
>
>
> {code:java}
> org.apache.geode.management.internal.cli.commands.RebalanceCommandDUnitTest >
> testWithTimeOutAndRegion FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2985
> [fatal 2019/10/21 13:15:18.178 GMT tid=716] Uncaught
> exception in thread Thread[FederatingManager3,5,RMI Runtime]
> org.apache.geode.cache.RegionDestroyedException:
> org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_172.17.0.1841001';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE]
> at
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251)
> at
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:453)
> at
> org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
> at
> org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67)
> at
> org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1203
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7330) CI Failure: RebalanceCommandDUnitTest > testWithTimeOutAndRegion FAILED
Ernest Burghardt created GEODE-7330:
---
Summary: CI Failure: RebalanceCommandDUnitTest >
testWithTimeOutAndRegion FAILED
Key: GEODE-7330
URL: https://issues.apache.org/jira/browse/GEODE-7330
Project: Geode
Issue Type: Test
Components: jmx
Reporter: Ernest Burghardt
{code:java}
org.apache.geode.management.internal.cli.commands.RebalanceCommandDUnitTest >
testWithTimeOutAndRegion FAILED
java.lang.AssertionError: Suspicious strings were written to the log during
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 2985
[fatal 2019/10/21 13:15:18.178 GMT tid=716] Uncaught
exception in thread Thread[FederatingManager3,5,RMI Runtime]
org.apache.geode.cache.RegionDestroyedException:
org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_172.17.0.1841001';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE]
at
org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157)
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128)
at
org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251)
at
org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:453)
at
org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
at
org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67)
at
org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1203
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7329) Document how to configure logging other than Log4j
Karen Smoler Miller created GEODE-7329: -- Summary: Document how to configure logging other than Log4j Key: GEODE-7329 URL: https://issues.apache.org/jira/browse/GEODE-7329 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller Now that Log4j is in its own module, users can configure their own non-Log4j logging system. We should tell users how to configure this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7264) Jackson-databind vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker resolved GEODE-7264. -- Resolution: Duplicate > Jackson-databind vulnerabilities > > > Key: GEODE-7264 > URL: https://issues.apache.org/jira/browse/GEODE-7264 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Gang Yan >Priority: Major > > In case it is by when the customer can expect a patch that addresses these > vulnerabilities? > [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814] > [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7264) Jackson-databind vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker closed GEODE-7264. > Jackson-databind vulnerabilities > > > Key: GEODE-7264 > URL: https://issues.apache.org/jira/browse/GEODE-7264 > Project: Geode > Issue Type: Bug > Components: rest (admin) >Reporter: Gang Yan >Priority: Major > > In case it is by when the customer can expect a patch that addresses these > vulnerabilities? > [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814] > [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-7328:
Assignee: Kirk Lund
> CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
>
>
> {code:java}
> org.apache.geode.distributed.ServerLauncherTest >
> startRunsExceptionActionAfterStartupTasksError FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsExceptionActionAfterStartupTasksError(ServerLauncherTest.java:368)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startRunsCompletionActionAfterStartupTasksComplete FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startRunsCompletionActionAfterStartupTasksComplete(ServerLauncherTest.java:346)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesControllableProcessFromBuilder FAILED java.lang.RuntimeException: An
> IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesControllableProcessFromBuilder(ServerLauncherTest.java:402)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startUsesCacheProviderFromBuilder FAILED java.lang.RuntimeException: An IO
> error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startUsesCacheProviderFromBuilder(ServerLauncherTest.java:385)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on localhost. at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
> ... 1 more org.apache.geode.distributed.ServerLauncherTest >
> startCacheServerDoesNothingWhenCacheServerAlreadyExists FAILED
> java.lang.RuntimeException: An IO error occurred while starting a Server in
> /home/geode/geode/geode-core/build/test on
> heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
> Network is unreachable; port (40404) is not available on localhost. at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
> org.apache.geode.distributed.ServerLauncherTest.startCacheServerDoesNothingWhenCacheServerAlreadyExists(ServerLauncherTest.java:324)
> Caused by: java.net.BindException: Network is unreachable; port (40404) is
> not available on
[jira] [Updated] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-7328:
Description:
{code:java}
org.apache.geode.distributed.ServerLauncherTest >
startRunsExceptionActionAfterStartupTasksError FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startRunsExceptionActionAfterStartupTasksError(ServerLauncherTest.java:368)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startRunsCompletionActionAfterStartupTasksComplete FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startRunsCompletionActionAfterStartupTasksComplete(ServerLauncherTest.java:346)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startUsesControllableProcessFromBuilder FAILED java.lang.RuntimeException: An
IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startUsesControllableProcessFromBuilder(ServerLauncherTest.java:402)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startUsesCacheProviderFromBuilder FAILED java.lang.RuntimeException: An IO
error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startUsesCacheProviderFromBuilder(ServerLauncherTest.java:385)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startCacheServerDoesNothingWhenCacheServerAlreadyExists FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startCacheServerDoesNothingWhenCacheServerAlreadyExists(ServerLauncherTest.java:324)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more{code}
UnitTestOpenJDK11 #1196:
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/1196]
was:
org.apache.geode.distributed.ServerLauncherTest >
startRunsExceptionActionAfterStartupTasksError FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
[jira] [Updated] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-7328:
Description:
org.apache.geode.distributed.ServerLauncherTest >
startRunsExceptionActionAfterStartupTasksError FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startRunsExceptionActionAfterStartupTasksError(ServerLauncherTest.java:368)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startRunsCompletionActionAfterStartupTasksComplete FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startRunsCompletionActionAfterStartupTasksComplete(ServerLauncherTest.java:346)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startUsesControllableProcessFromBuilder FAILED java.lang.RuntimeException: An
IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startUsesControllableProcessFromBuilder(ServerLauncherTest.java:402)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startUsesCacheProviderFromBuilder FAILED java.lang.RuntimeException: An IO
error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startUsesCacheProviderFromBuilder(ServerLauncherTest.java:385)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more org.apache.geode.distributed.ServerLauncherTest >
startCacheServerDoesNothingWhenCacheServerAlreadyExists FAILED
java.lang.RuntimeException: An IO error occurred while starting a Server in
/home/geode/geode/geode-core/build/test on
heavy-lifter-fac2da6c-bacb-5e92-9cf1-b8cdb36d3b27.c.apachegeode-ci.internal[40404]:
Network is unreachable; port (40404) is not available on localhost. at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:854) at
org.apache.geode.distributed.ServerLauncherTest.startCacheServerDoesNothingWhenCacheServerAlreadyExists(ServerLauncherTest.java:324)
Caused by: java.net.BindException: Network is unreachable; port (40404) is not
available on localhost. at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:796)
... 1 more
was:
{noformat}
org.apache.geode.distributed.ServerLauncherTest >
startWaitsForStartupTasksToComplete FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in org.apache.geode.distributed.ServerLauncherTest that
uses java.util.concurrent.CompletableFuture
Wanted but not invoked:
completableFuture.thenRun();
->
[jira] [Updated] (GEODE-7328) CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-7328:
Summary: CI Failure:
org.apache.geode.distributed.ServerLauncherTest(s)failed (was: CLONE - CI
Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed)
> CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherTest >
> startWaitsForStartupTasksToComplete FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.distributed.ServerLauncherTest that uses
> java.util.concurrent.CompletableFuture
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> 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.distributed.ServerLauncherTest.startWaitsForStartupTasksToComplete(ServerLauncherTest.java:428)
> Caused by:
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> {noformat}
> UnitTestOpenJDK11 #943:
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/UnitTestOpenJDK11/builds/943
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-results/test/1568154432/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-artifacts/1568154432/unittestfiles-OpenJDK11-9.10.0-build.0108.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7328) CLONE - CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
Ernest Burghardt created GEODE-7328:
---
Summary: CLONE - CI Failure:
org.apache.geode.distributed.ServerLauncherTest(s)failed
Key: GEODE-7328
URL: https://issues.apache.org/jira/browse/GEODE-7328
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Ernest Burghardt
Assignee: Kirk Lund
Fix For: 1.11.0
{noformat}
org.apache.geode.distributed.ServerLauncherTest >
startWaitsForStartupTasksToComplete FAILED
org.awaitility.core.ConditionTimeoutException: Assertion condition defined
as a lambda expression in org.apache.geode.distributed.ServerLauncherTest that
uses java.util.concurrent.CompletableFuture
Wanted but not invoked:
completableFuture.thenRun();
-> at
org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
Actually, there were zero interactions with this mock.
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.distributed.ServerLauncherTest.startWaitsForStartupTasksToComplete(ServerLauncherTest.java:428)
Caused by:
Wanted but not invoked:
completableFuture.thenRun();
-> at
org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
Actually, there were zero interactions with this mock.
at
org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
{noformat}
UnitTestOpenJDK11 #943:
https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/UnitTestOpenJDK11/builds/943
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-results/test/1568154432/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Test report artifacts from this job are available at:
gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-artifacts/1568154432/unittestfiles-OpenJDK11-9.10.0-build.0108.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7328) CLONE - CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-7328:
Fix Version/s: (was: 1.11.0)
> CLONE - CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherTest >
> startWaitsForStartupTasksToComplete FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.distributed.ServerLauncherTest that uses
> java.util.concurrent.CompletableFuture
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> 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.distributed.ServerLauncherTest.startWaitsForStartupTasksToComplete(ServerLauncherTest.java:428)
> Caused by:
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> {noformat}
> UnitTestOpenJDK11 #943:
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/UnitTestOpenJDK11/builds/943
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-results/test/1568154432/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-artifacts/1568154432/unittestfiles-OpenJDK11-9.10.0-build.0108.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7328) CLONE - CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
[
https://issues.apache.org/jira/browse/GEODE-7328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt reassigned GEODE-7328:
---
Assignee: (was: Kirk Lund)
> CLONE - CI Failure: org.apache.geode.distributed.ServerLauncherTest(s)failed
>
>
> Key: GEODE-7328
> URL: https://issues.apache.org/jira/browse/GEODE-7328
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Ernest Burghardt
>Priority: Major
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherTest >
> startWaitsForStartupTasksToComplete FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.distributed.ServerLauncherTest that uses
> java.util.concurrent.CompletableFuture
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> 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.distributed.ServerLauncherTest.startWaitsForStartupTasksToComplete(ServerLauncherTest.java:428)
> Caused by:
> Wanted but not invoked:
> completableFuture.thenRun();
> -> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> Actually, there were zero interactions with this mock.
> at
> org.apache.geode.distributed.ServerLauncherTest.lambda$startWaitsForStartupTasksToComplete$14(ServerLauncherTest.java:428)
> {noformat}
> UnitTestOpenJDK11 #943:
> https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/UnitTestOpenJDK11/builds/943
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-results/test/1568154432/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> gs://gemfire-test-artifacts/builds/gemfire-develop-main/9.10.0-build.0108/test-artifacts/1568154432/unittestfiles-OpenJDK11-9.10.0-build.0108.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7327) Collapse InternalDistributedMember, NetMember, GMSMemberAdapter, and GMSMember
Bill Burcham created GEODE-7327: --- Summary: Collapse InternalDistributedMember, NetMember, GMSMemberAdapter, and GMSMember Key: GEODE-7327 URL: https://issues.apache.org/jira/browse/GEODE-7327 Project: Geode Issue Type: Bug Components: membership Reporter: Bill Burcham Fix For: 1.11.0 All of these classes contain member id information that is required by geode-core (durable client attributes). So there is not really any reason to have so many different nested classes and abstractions. Turn these all into a single object. One important benefit of this work is that it will simplify our interprocess communication. For instance, we won't be sending around GMSMember any more. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7303) Native Client user guides: Simplify builds
[ https://issues.apache.org/jira/browse/GEODE-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-7303. Fix Version/s: 1.11.0 Resolution: Fixed > Native Client user guides: Simplify builds > -- > > Key: GEODE-7303 > URL: https://issues.apache.org/jira/browse/GEODE-7303 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.11.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > The C++ and .NET client guides have been separated (GEODE-7262). However, the > current build procedure allows only one book to be built at a time. > Generating the alternative manual requires switching config files. We need a > simpler scheme. Two ideas to pursue: > * Separate 'book' directories > * Scripts > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7303) Native Client user guides: Simplify builds
[ https://issues.apache.org/jira/browse/GEODE-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956264#comment-16956264 ] ASF subversion and git services commented on GEODE-7303: Commit bf7b27371ac8e48059ef4e240d296c9bb14d32d7 in geode-native's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=bf7b273 ] GEODE-7303: Simplify nc ug builds - remove some redundant files (#540) > Native Client user guides: Simplify builds > -- > > Key: GEODE-7303 > URL: https://issues.apache.org/jira/browse/GEODE-7303 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > The C++ and .NET client guides have been separated (GEODE-7262). However, the > current build procedure allows only one book to be built at a time. > Generating the alternative manual requires switching config files. We need a > simpler scheme. Two ideas to pursue: > * Separate 'book' directories > * Scripts > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7321) Move and Rename ConnectionDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956256#comment-16956256
]
ASF subversion and git services commented on GEODE-7321:
Commit bd0b6fd75f245283092574428b7cb16a94dff75e in geode's branch
refs/heads/feature/GEODE-7258 from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bd0b6fd ]
GEODE-7321: Move and Rename ConnectionDUnitTest
Moving this to be an integration test instead of a distributed test.
It ought to be a regular unit test but capturing Geode log output with
SystemOutRule doesn't seem to work anymore.
> Move and Rename ConnectionDUnitTest
>
>
> Key: GEODE-7321
> URL: https://issues.apache.org/jira/browse/GEODE-7321
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan Ramos
>Priority: Trivial
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test uses one single VM so it shouldn't be under the {{distributedTest}}
> folder, neither should it use the {{DistributedRule}} class. Refactor the
> test and move it to {{integrationTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7184) Add function execution timers
[ https://issues.apache.org/jira/browse/GEODE-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956257#comment-16956257 ] ASF subversion and git services commented on GEODE-7184: Commit 75c63420f63eb942b403599bb4064506c6f7b0f9 in geode's branch refs/heads/feature/GEODE-7258 from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=75c6342 ] GEODE-7184: Add function execution timers (#4135) - Add micrometer timers for recording function executions - Refactor FunctionStats and FunctionServiceStats - Change static fields to instance fields on FunctionStatsManager - Mark static field as @Immutable on NoopMeterRegistry - Rename FunctionServiceStats.endFunctionExecutionWithElapsedTime to distinguish it from FunctionStats.endFunctionExecution which takes a start time. - Remove extra call to FunctionStats.getTime() in MemberFunctionStreamingMessage and add boolean to prevent calling endFunctionExecutionWithException before startFunctionExecution was called. - Remove FunctionStats.getTime() in favor of returning the time from FunctionStats.startFunctionExecution() Functions with hasResult()=false execute asynchronously on an executor. Previously, the instrumentation code recorded a successful function execution after submitting a function to an executor, which is incorrect because the function has not necessarily executed at that point. Now, we record the execution time only after the function actually executes. Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund Co-authored-by: Dale Emery Co-authored-by: Mark Hanson > Add function execution timers > - > > Key: GEODE-7184 > URL: https://issues.apache.org/jira/browse/GEODE-7184 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > Developers oftentimes deploy their own functions to the system to enable > decorator pattern for caching to add information to specific key/value pairs. > In doing so, they can introduce bottlenecks into the system where server-side > functions can cause issues or make things slower than intended. We want a way > that users can view functions that they create, and see what the average > execution time looks like. > * *Meter Type*: Timer > * *Name*: geode.function.executions > * *Description*: TBD > * *Tags*: , function (getId on function, if DNE present > getClass.getname of deployed function), succeeded (true/false) > h3. Acceptance Criteria > *Meter creation/deletion*: Create meter on function execution > *Measurement*: On an individual server, start the timer when a *USER* > function is invoked/executed, and stop the timer when the user function > completes OR errors. If it throws a Function Execution or another error then > the tag function.isSuccessful=false > Details on Functions and their execution: > [https://geode.apache.org/docs/guide/110/developing/function_exec/function_execution.html] > h3. Scenarios > *Scenario: The timers are created when the function is first executed* > Given a user executed a function with ID functionToTime on a cluster with 1 > locator/1 server > And functionToTime has not been executed previously > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count > 1 > - totalTime >= 5,000,000,000ns > And the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 0 > - totalTime = 0 > *Scenario: Successful singular function execution (registered execution)* > Given a user registers a function with ID functionToTime (that waits for 5 > seconds) on a cluster with 1 locator/1 server > When functionToTime is triggered using gfsh command: "execute function > --id=functionToTime" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Successful singular function execution (unregistered execution)* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using > "FunctionService.onServers(cache).execute(new FunctionToTime())" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Singular function execution with Any Exception* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using >
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956258#comment-16956258 ] ASF subversion and git services commented on GEODE-6807: Commit e225ffcd5dc8f15ae59b46dc24baefcc253801f2 in geode's branch refs/heads/feature/GEODE-7258 from Ernie Burghardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e225ffc ] Revert "GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached" (#4189) CI failing during pre-checkin, this should have be resolved prior to Merging > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7258) RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated > test[from_v1.10.0, with reindex=true] FAILED
[
https://issues.apache.org/jira/browse/GEODE-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956259#comment-16956259
]
ASF subversion and git services commented on GEODE-7258:
Commit c435cede56e72f905ab3f4a82dfd38cf99a18dbd in geode's branch
refs/heads/feature/GEODE-7258 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c435ced ]
GEODE-7258: The function retry logic is modified to handle exception
thrown, while trying to connect to a server thats shutdown/closed.
Co-authored-by: Anil
Co-authored-by: Xiaojian Zhou
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> --
>
> Key: GEODE-7258
> URL: https://issues.apache.org/jira/browse/GEODE-7258
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.10.0
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
> Attachments: runsWithFineLevelLogging.zip
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> This test is failing repeatedly. The logs do not to my eyes indicate what is
> the source of the problem.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1112]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1113]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-results/upgradeTest/1569861659/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-artifacts/1569861659/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0169.tgz
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/upgradeTest/1569863814/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-artifacts/1569863814/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0170.tgz
>
> {noformat}
> Task :geode-lucene:upgradeTest
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated$$Lambda$172/0x0008407b2440.run
> in VM 3 running on Host 38006782570a with 4 VMs with version 1.10.0
> 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.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> java.lang.reflect.InvocationTargetException
> 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.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:381)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.lambda$test$c93719d5$2(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerConnectivityException: Could not create a
> new connection to server 38006782570a:24478
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:209)
> at
>
[jira] [Commented] (GEODE-7320) Rename isKnownDangerousMethod
[
https://issues.apache.org/jira/browse/GEODE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956255#comment-16956255
]
ASF subversion and git services commented on GEODE-7320:
Commit 03b504bc32c6b4f5e07b3c5e1184894d9eeb7541 in geode's branch
refs/heads/feature/GEODE-7258 from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=03b504b ]
GEODE-7320: Rename isKnownDangerousMethod (#4183)
- Method renamed to better reflect its intent.
> Rename isKnownDangerousMethod
> -
>
> Key: GEODE-7320
> URL: https://issues.apache.org/jira/browse/GEODE-7320
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While reviewing [Pull Request
> 4123|https://github.com/apache/geode/pull/4123], [~nabarunnag]
> [suggested|https://github.com/apache/geode/pull/4123#discussion_r332702167]
> to change the name of the {{isKnownDangerousMethod()}} method in the
> {{RestrictedMethodAuthorizer}} class.
> Evaluate the suggested options and rename the method to better reflect its
> intent (the changes should also be reflected in the [RFC Errata
> section|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Errata]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956251#comment-16956251 ] ASF subversion and git services commented on GEODE-6807: Commit e225ffcd5dc8f15ae59b46dc24baefcc253801f2 in geode's branch refs/heads/develop from Ernie Burghardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e225ffc ] Revert "GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached" (#4189) CI failing during pre-checkin, this should have be resolved prior to Merging > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4h 50m > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7326) Add cache gets timer
Aaron Lindsey created GEODE-7326: Summary: Add cache gets timer Key: GEODE-7326 URL: https://issues.apache.org/jira/browse/GEODE-7326 Project: Geode Issue Type: Improvement Reporter: Aaron Lindsey h3. Why Users want to understand the performance of their operations within the server. h3. Acceptance Criteria Type: timer Name: geode.cache.gets Tags: region, result=hit/miss Lifecycle of meter: The hit/miss meter for each region is created when the first GET on that user region happens. The meter(s) are only removed when the cache is closed. Description for meter: The total time and count for GET requests from clients. Thing to measure : A count and total time for GET operations that didn't error, by this specific Server (1 or many cacheservers) in the geode cluster from when the server receives the request to when it sends the response. Business Rule for this measurement: This meter records any operation sent through a CacheServer h3. Scenarios *Scenario: Java Client Hits* Given a cluster with a Server1 and a Locator1 When the oldest supported java client issues 5 get operations using the region.get(key) command Then a meter on Server1 exists such that: - Meter Name = 'geode.cache.gets' - Count = 5 - Total Time = total time spent from received request to response to client for these 5 requests - Tag: region = region that the 'get' method was called against - Tag: result=hit *Scenario: Java Client Misses* Given a cluster with a Server1 and a Locator1 When the oldest supported java client issues 5 get operations where the user is getting a key that doesn't exist in the region using the region.get(key) command Then a meter on Server1 exists such that: - Meter Name = 'geode.cache.gets' - Count = 5 - Total Time = total time spent from received request to response to client for these 5 requests - Tag: region = region that the 'get' method was called against - Tag: result=miss *Scenario: Java client error response* Given a cluster with a Server1 And a RegionA exists with NO entry with a Key="1" And a CacheLoader that throws an exception when invoked When the client issues a region.get(1) request Then no meter on Server1 should exist like: - Meter Name = 'geode.cache.gets' - Tag: region = RegionA -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956247#comment-16956247 ] ASF subversion and git services commented on GEODE-6807: Commit a7a5ecdde06ee38c9a6d98e888a65084c283e8c6 in geode's branch refs/heads/revert-4086-feature/GEODE-6807 from Ernie Burghardt [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a7a5ecd ] Revert "GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached" > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7184) Add function execution timers
[ https://issues.apache.org/jira/browse/GEODE-7184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956237#comment-16956237 ] ASF subversion and git services commented on GEODE-7184: Commit 75c63420f63eb942b403599bb4064506c6f7b0f9 in geode's branch refs/heads/develop from Aaron Lindsey [ https://gitbox.apache.org/repos/asf?p=geode.git;h=75c6342 ] GEODE-7184: Add function execution timers (#4135) - Add micrometer timers for recording function executions - Refactor FunctionStats and FunctionServiceStats - Change static fields to instance fields on FunctionStatsManager - Mark static field as @Immutable on NoopMeterRegistry - Rename FunctionServiceStats.endFunctionExecutionWithElapsedTime to distinguish it from FunctionStats.endFunctionExecution which takes a start time. - Remove extra call to FunctionStats.getTime() in MemberFunctionStreamingMessage and add boolean to prevent calling endFunctionExecutionWithException before startFunctionExecution was called. - Remove FunctionStats.getTime() in favor of returning the time from FunctionStats.startFunctionExecution() Functions with hasResult()=false execute asynchronously on an executor. Previously, the instrumentation code recorded a successful function execution after submitting a function to an executor, which is incorrect because the function has not necessarily executed at that point. Now, we record the execution time only after the function actually executes. Co-authored-by: Aaron Lindsey Co-authored-by: Kirk Lund Co-authored-by: Dale Emery Co-authored-by: Mark Hanson > Add function execution timers > - > > Key: GEODE-7184 > URL: https://issues.apache.org/jira/browse/GEODE-7184 > Project: Geode > Issue Type: Improvement >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Time Spent: 4h 50m > Remaining Estimate: 0h > > Developers oftentimes deploy their own functions to the system to enable > decorator pattern for caching to add information to specific key/value pairs. > In doing so, they can introduce bottlenecks into the system where server-side > functions can cause issues or make things slower than intended. We want a way > that users can view functions that they create, and see what the average > execution time looks like. > * *Meter Type*: Timer > * *Name*: geode.function.executions > * *Description*: TBD > * *Tags*: , function (getId on function, if DNE present > getClass.getname of deployed function), succeeded (true/false) > h3. Acceptance Criteria > *Meter creation/deletion*: Create meter on function execution > *Measurement*: On an individual server, start the timer when a *USER* > function is invoked/executed, and stop the timer when the user function > completes OR errors. If it throws a Function Execution or another error then > the tag function.isSuccessful=false > Details on Functions and their execution: > [https://geode.apache.org/docs/guide/110/developing/function_exec/function_execution.html] > h3. Scenarios > *Scenario: The timers are created when the function is first executed* > Given a user executed a function with ID functionToTime on a cluster with 1 > locator/1 server > And functionToTime has not been executed previously > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count > 1 > - totalTime >= 5,000,000,000ns > And the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = false > - count = 0 > - totalTime = 0 > *Scenario: Successful singular function execution (registered execution)* > Given a user registers a function with ID functionToTime (that waits for 5 > seconds) on a cluster with 1 locator/1 server > When functionToTime is triggered using gfsh command: "execute function > --id=functionToTime" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Successful singular function execution (unregistered execution)* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using > "FunctionService.onServers(cache).execute(new FunctionToTime())" > And the function completes without error > Then the server has the following timer: > - name: geode.function.executions > - tag: id = functionToTime > - tag: succeeded = true > - count = 1 > - totalTime >= 5,000,000,000ns > *Scenario: Singular function execution with Any Exception* > Given an unregistered function with ID functionToTime (that waits for 5 > seconds) exists > When triggered on a client using >
[jira] [Resolved] (GEODE-7321) Move and Rename ConnectionDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-7321.
---
Fix Version/s: 1.11.0
Resolution: Fixed
test rename & simplification from dunit to integration test
> Move and Rename ConnectionDUnitTest
>
>
> Key: GEODE-7321
> URL: https://issues.apache.org/jira/browse/GEODE-7321
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan Ramos
>Priority: Trivial
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test uses one single VM so it shouldn't be under the {{distributedTest}}
> folder, neither should it use the {{DistributedRule}} class. Refactor the
> test and move it to {{integrationTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7321) Move and Rename ConnectionDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-7321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956196#comment-16956196
]
ASF subversion and git services commented on GEODE-7321:
Commit bd0b6fd75f245283092574428b7cb16a94dff75e in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=bd0b6fd ]
GEODE-7321: Move and Rename ConnectionDUnitTest
Moving this to be an integration test instead of a distributed test.
It ought to be a regular unit test but capturing Geode log output with
SystemOutRule doesn't seem to work anymore.
> Move and Rename ConnectionDUnitTest
>
>
> Key: GEODE-7321
> URL: https://issues.apache.org/jira/browse/GEODE-7321
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Juan Ramos
>Priority: Trivial
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The test uses one single VM so it shouldn't be under the {{distributedTest}}
> folder, neither should it use the {{DistributedRule}} class. Refactor the
> test and move it to {{integrationTest}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7303) Native Client user guides: Simplify builds
[ https://issues.apache.org/jira/browse/GEODE-7303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956069#comment-16956069 ] ASF subversion and git services commented on GEODE-7303: Commit 6890280df626ddd31841bc66a7aeac0cadc2c902 in geode-native's branch refs/heads/develop from Alberto Bustamante Reyes [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=6890280 ] GEODE-7303: Fix link in README (#541) > Native Client user guides: Simplify builds > -- > > Key: GEODE-7303 > URL: https://issues.apache.org/jira/browse/GEODE-7303 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > The C++ and .NET client guides have been separated (GEODE-7262). However, the > current build procedure allows only one book to be built at a time. > Generating the alternative manual requires switching config files. We need a > simpler scheme. Two ideas to pursue: > * Separate 'book' directories > * Scripts > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7320) Rename isKnownDangerousMethod
[
https://issues.apache.org/jira/browse/GEODE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Juan Ramos resolved GEODE-7320.
---
Fix Version/s: 1.11.0
Resolution: Fixed
> Rename isKnownDangerousMethod
> -
>
> Key: GEODE-7320
> URL: https://issues.apache.org/jira/browse/GEODE-7320
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Fix For: 1.11.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While reviewing [Pull Request
> 4123|https://github.com/apache/geode/pull/4123], [~nabarunnag]
> [suggested|https://github.com/apache/geode/pull/4123#discussion_r332702167]
> to change the name of the {{isKnownDangerousMethod()}} method in the
> {{RestrictedMethodAuthorizer}} class.
> Evaluate the suggested options and rename the method to better reflect its
> intent (the changes should also be reflected in the [RFC Errata
> section|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Errata]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7320) Rename isKnownDangerousMethod
[
https://issues.apache.org/jira/browse/GEODE-7320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956000#comment-16956000
]
ASF subversion and git services commented on GEODE-7320:
Commit 03b504bc32c6b4f5e07b3c5e1184894d9eeb7541 in geode's branch
refs/heads/develop from Juan José Ramos
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=03b504b ]
GEODE-7320: Rename isKnownDangerousMethod (#4183)
- Method renamed to better reflect its intent.
> Rename isKnownDangerousMethod
> -
>
> Key: GEODE-7320
> URL: https://issues.apache.org/jira/browse/GEODE-7320
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
> Labels: GeodeCommons
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While reviewing [Pull Request
> 4123|https://github.com/apache/geode/pull/4123], [~nabarunnag]
> [suggested|https://github.com/apache/geode/pull/4123#discussion_r332702167]
> to change the name of the {{isKnownDangerousMethod()}} method in the
> {{RestrictedMethodAuthorizer}} class.
> Evaluate the suggested options and rename the method to better reflect its
> intent (the changes should also be reflected in the [RFC Errata
> section|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-Errata]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955793#comment-16955793 ] ASF subversion and git services commented on GEODE-6807: Commit 5046c70d6b5458027c51265a178107c50540a0bf in geode's branch refs/heads/feature/GEODE-7258 from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5046c70 ] Merge pull request #4086 from Nordix/feature/GEODE-6807 GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955786#comment-16955786 ] ASF subversion and git services commented on GEODE-6807: Commit 097de3de9260d98bd8ef426418ec0154be206591 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=097de3d ] GEODE-6807: update with comments > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955792#comment-16955792 ] ASF subversion and git services commented on GEODE-6807: Commit 794eddabd9532dce44927ee6601eee242d9fd0e8 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=794edda ] GEODE-6807: Added missing @Test and rebase > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955791#comment-16955791 ] ASF subversion and git services commented on GEODE-6807: Commit e0bfae6a101267effcc8795460d4361138e182b3 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0bfae6 ] GEODE-6807: Added Concurrent Test > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7258) RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated > test[from_v1.10.0, with reindex=true] FAILED
[
https://issues.apache.org/jira/browse/GEODE-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955795#comment-16955795
]
ASF subversion and git services commented on GEODE-7258:
Commit c8688091de1a6b14254a91139c8c831ef8b94b41 in geode's branch
refs/heads/feature/GEODE-7258 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c868809 ]
GEODE-7258: The function retry logic is modified to handle exception
thrown, while trying to connect to a server thats shutdown/closed.
Co-authored-by: Anil
Co-authored-by: Xiaojian Zhou
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> --
>
> Key: GEODE-7258
> URL: https://issues.apache.org/jira/browse/GEODE-7258
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.10.0
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
> Attachments: runsWithFineLevelLogging.zip
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> This test is failing repeatedly. The logs do not to my eyes indicate what is
> the source of the problem.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1112]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1113]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-results/upgradeTest/1569861659/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-artifacts/1569861659/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0169.tgz
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/upgradeTest/1569863814/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-artifacts/1569863814/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0170.tgz
>
> {noformat}
> Task :geode-lucene:upgradeTest
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated$$Lambda$172/0x0008407b2440.run
> in VM 3 running on Host 38006782570a with 4 VMs with version 1.10.0
> 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.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> java.lang.reflect.InvocationTargetException
> 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.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:381)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.lambda$test$c93719d5$2(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerConnectivityException: Could not create a
> new connection to server 38006782570a:24478
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:209)
> at
>
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955785#comment-16955785 ] ASF subversion and git services commented on GEODE-6807: Commit 0f8248ab93ce2e10dc84baa668e163af2b9a5974 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f8248a ] GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955794#comment-16955794 ] ASF subversion and git services commented on GEODE-6807: Commit 5046c70d6b5458027c51265a178107c50540a0bf in geode's branch refs/heads/feature/GEODE-7258 from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5046c70 ] Merge pull request #4086 from Nordix/feature/GEODE-6807 GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955790#comment-16955790 ] ASF subversion and git services commented on GEODE-6807: Commit 928e6cd59a64efbb2f720176d15a761acdc07e64 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=928e6cd ] GEODE-6807: Added UT and inRecovery update check > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955788#comment-16955788 ] ASF subversion and git services commented on GEODE-6807: Commit ac689a8293dc700d3f85090ce3941a664a2d2785 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ac689a8 ] GEODE-6807: update of solution with checking of version > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955789#comment-16955789 ] ASF subversion and git services commented on GEODE-6807: Commit 07b18a0cba1949a310c2e15d332b74dfa043c336 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07b18a0 ] GEODE-6807: remove assert from new code > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955787#comment-16955787 ] ASF subversion and git services commented on GEODE-6807: Commit 0ab8b6b68642ab2efc29275e49b50fb7a80c9adc in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ab8b6b ] GEODE-6807: update adviseAllEventsOrCached method > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955777#comment-16955777 ] ASF subversion and git services commented on GEODE-6807: Commit 07b18a0cba1949a310c2e15d332b74dfa043c336 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07b18a0 ] GEODE-6807: remove assert from new code > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955776#comment-16955776 ] ASF subversion and git services commented on GEODE-6807: Commit ac689a8293dc700d3f85090ce3941a664a2d2785 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ac689a8 ] GEODE-6807: update of solution with checking of version > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955775#comment-16955775 ] ASF subversion and git services commented on GEODE-6807: Commit 0ab8b6b68642ab2efc29275e49b50fb7a80c9adc in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0ab8b6b ] GEODE-6807: update adviseAllEventsOrCached method > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955779#comment-16955779 ] ASF subversion and git services commented on GEODE-6807: Commit e0bfae6a101267effcc8795460d4361138e182b3 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e0bfae6 ] GEODE-6807: Added Concurrent Test > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955778#comment-16955778 ] ASF subversion and git services commented on GEODE-6807: Commit 928e6cd59a64efbb2f720176d15a761acdc07e64 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=928e6cd ] GEODE-6807: Added UT and inRecovery update check > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955780#comment-16955780 ] ASF subversion and git services commented on GEODE-6807: Commit 794eddabd9532dce44927ee6601eee242d9fd0e8 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=794edda ] GEODE-6807: Added missing @Test and rebase > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955782#comment-16955782 ] ASF subversion and git services commented on GEODE-6807: Commit 5046c70d6b5458027c51265a178107c50540a0bf in geode's branch refs/heads/feature/GEODE-7258 from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5046c70 ] Merge pull request #4086 from Nordix/feature/GEODE-6807 GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7258) RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated > test[from_v1.10.0, with reindex=true] FAILED
[
https://issues.apache.org/jira/browse/GEODE-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955783#comment-16955783
]
ASF subversion and git services commented on GEODE-7258:
Commit c8688091de1a6b14254a91139c8c831ef8b94b41 in geode's branch
refs/heads/feature/GEODE-7258 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c868809 ]
GEODE-7258: The function retry logic is modified to handle exception
thrown, while trying to connect to a server thats shutdown/closed.
Co-authored-by: Anil
Co-authored-by: Xiaojian Zhou
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> --
>
> Key: GEODE-7258
> URL: https://issues.apache.org/jira/browse/GEODE-7258
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.10.0
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
> Attachments: runsWithFineLevelLogging.zip
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> This test is failing repeatedly. The logs do not to my eyes indicate what is
> the source of the problem.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1112]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1113]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-results/upgradeTest/1569861659/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-artifacts/1569861659/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0169.tgz
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/upgradeTest/1569863814/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-artifacts/1569863814/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0170.tgz
>
> {noformat}
> Task :geode-lucene:upgradeTest
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated$$Lambda$172/0x0008407b2440.run
> in VM 3 running on Host 38006782570a with 4 VMs with version 1.10.0
> 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.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> java.lang.reflect.InvocationTargetException
> 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.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:381)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.lambda$test$c93719d5$2(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerConnectivityException: Could not create a
> new connection to server 38006782570a:24478
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:209)
> at
>
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955773#comment-16955773 ] ASF subversion and git services commented on GEODE-6807: Commit 0f8248ab93ce2e10dc84baa668e163af2b9a5974 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0f8248a ] GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955781#comment-16955781 ] ASF subversion and git services commented on GEODE-6807: Commit 5046c70d6b5458027c51265a178107c50540a0bf in geode's branch refs/heads/feature/GEODE-7258 from Mario Ivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5046c70 ] Merge pull request #4086 from Nordix/feature/GEODE-6807 GEODE-6807: cache adviseUpdate and adviseAllEventsOrCached > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6807) changing advisors to cache advice can improve performance
[ https://issues.apache.org/jira/browse/GEODE-6807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955774#comment-16955774 ] ASF subversion and git services commented on GEODE-6807: Commit 097de3de9260d98bd8ef426418ec0154be206591 in geode's branch refs/heads/feature/GEODE-7258 from mivanac [ https://gitbox.apache.org/repos/asf?p=geode.git;h=097de3d ] GEODE-6807: update with comments > changing advisors to cache advice can improve performance > - > > Key: GEODE-6807 > URL: https://issues.apache.org/jira/browse/GEODE-6807 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Mario Ivanac >Priority: Major > Labels: performance > Time Spent: 4.5h > Remaining Estimate: 0h > > Cluster messaging uses advisors to know what member of the cluster should be > sent a message. > Currently, every time and advisor is asked for advice to iterates over its > profiles building up the advice in a HashSet that is returned. > I found on a partitioned region client/server put benchmark (32 client > threads, 2 servers with redundancy 1) that if I changed the method > adviseAllEventsOrCached to remember what it computed, that it caused the put > throughput to increase by 8%. [Update I reran and did not see an improvement > so the original 8% difference may have been caused by something else]. > Advisors know when a profile is added, removed, or modified. When that > happens any advice it has cached can be dropped. Also, the requestors of > advice need to expect the Set they get back to be unmodifiable. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7258) RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated > test[from_v1.10.0, with reindex=true] FAILED
[
https://issues.apache.org/jira/browse/GEODE-7258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16955771#comment-16955771
]
ASF subversion and git services commented on GEODE-7258:
Commit 924d60f028ffee5325596244b6f457153ce728d0 in geode's branch
refs/heads/feature/GEODE-7258 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=924d60f ]
GEODE-7258: The function retry logic is modified to handle exception
thrown, while trying to connect to a server thats shutdown/closed.
Co-authored-by: Anil
Co-authored-by: Xiaojian Zhou
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> --
>
> Key: GEODE-7258
> URL: https://issues.apache.org/jira/browse/GEODE-7258
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.10.0
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
> Labels: GeodeCommons
> Attachments: runsWithFineLevelLogging.zip
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> This test is failing repeatedly. The logs do not to my eyes indicate what is
> the source of the problem.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1112]
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/1113]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-results/upgradeTest/1569861659/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0169/test-artifacts/1569861659/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0169.tgz
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-results/upgradeTest/1569863814/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0170/test-artifacts/1569863814/upgradetestfiles-OpenJDK11-1.11.0-SNAPSHOT.0170.tgz
>
> {noformat}
> Task :geode-lucene:upgradeTest
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> > test[from_v1.10.0, with reindex=true] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated$$Lambda$172/0x0008407b2440.run
> in VM 3 running on Host 38006782570a with 4 VMs with version 1.10.0
> 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.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> java.lang.reflect.InvocationTargetException
> 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.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.verifyLuceneQueryResults(LuceneSearchWithRollingUpgradeDUnit.java:381)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.lambda$test$c93719d5$2(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:111)
> Caused by:
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerConnectivityException: Could not create a
> new connection to server 38006782570a:24478
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:209)
> at
>
