[jira] [Commented] (GEODE-8318) Shutdown hang and abort
[ https://issues.apache.org/jira/browse/GEODE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235984#comment-17235984 ] ASF GitHub Bot commented on GEODE-8318: --- lgtm-com[bot] commented on pull request #695: URL: https://github.com/apache/geode-native/pull/695#issuecomment-731017541 This pull request **fixes 2 alerts** when merging 181595a7b03e936e27c405deca598b0fc7b6de09 into fcf95b32773783e86976e34c0ccfc9987fa63fec - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-ad2cf8953743a67188ac2ef0f628cc06f3487d42) **fixed alerts:** * 2 for Comparison result is always the same This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Shutdown hang and abort > --- > > Key: GEODE-8318 > URL: https://issues.apache.org/jira/browse/GEODE-8318 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Matthew Reddington >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > Switching from Ace to Boost.Asio has revealed threading issues related to > shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8704) many CI failures in Jetty9CachingClientServerTest
[
https://issues.apache.org/jira/browse/GEODE-8704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-8704.
-
Fix Version/s: 1.14.0
Resolution: Fixed
> many CI failures in Jetty9CachingClientServerTest
> -
>
> Key: GEODE-8704
> URL: https://issues.apache.org/jira/browse/GEODE-8704
> Project: Geode
> Issue Type: Bug
> Components: http session
>Affects Versions: 1.14.0
>Reporter: Kamilla Aslami
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> A bunch of failures:
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:434)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:102)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:57)
> Caused by:
> java.lang.IllegalStateException: Session is invalid
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.checkValid(GemfireHttpSession.java:317)
> at
> org.apache.geode.modules.session.internal.filter.GemfireHttpSession.setAttribute(GemfireHttpSession.java:301)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$null$0(Jetty9CachingClientServerTest.java:60)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at
> java.util.Collections$UnmodifiableCollection.forEach(Collections.java:1085)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.lambda$shouldCacheSessionOnClient$6b5e8371$1(Jetty9CachingClientServerTest.java:60)org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > shouldNotLeaveNativeSessionInContainer FAILED
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldReplicateCookies FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
>
> java.util.concurrent.TimeoutExceptionorg.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldShareSessionExpirationReset FAILED
> org.junit.ComparisonFailure:
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldExpireInSetTimeframe FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > containersShouldHavePersistentSessionData FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > failureShouldStillAllowOtherContainersDataAccess FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.session.tests.CargoTestBase Sessions are not replicating
> properly expected: but
> was: within 5 minutes.
> Caused by:
> org.junit.ComparisonFailure: Sessions are not replicating properly
> expected: but
> was:org.apache.geode.session.tests.Jetty9CachingClientServerTest
> > invalidationShouldRemoveValueAccessForAllContainers FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 1 running
> on Host e4bd15534025 with 4 VMsCaused by:
> org.awaitility.core.ConditionTimeoutException: Condition with alias
> 'for region to be empty' didn't complete within 5 minutes because assertion
> condition defined as a lamb
[jira] [Assigned] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-8738: Assignee: Alberto Gomez > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
Alberto Gomez created GEODE-8738: Summary: Document how to Configure just one IP address and port to access all gateway receivers in a site Key: GEODE-8738 URL: https://issues.apache.org/jira/browse/GEODE-8738 Project: Geode Issue Type: Improvement Components: docs, wan Reporter: Alberto Gomez The aim of this ticket is provide information in the Geode documentation on how to configure WAN deployments in which the gateway receivers are hidden behind the same IP address and port after some improvements and fixes have been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236032#comment-17236032 ] ASF GitHub Bot commented on GEODE-8738: --- albertogpz opened a new pull request #5766: URL: https://github.com/apache/geode/pull/5766 …th the same IP address and port for all gateway receivers Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8738: -- Labels: pull-request-available (was: ) > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236033#comment-17236033 ] ASF GitHub Bot commented on GEODE-8656: --- albertogpz commented on pull request #5670: URL: https://github.com/apache/geode/pull/5670#issuecomment-731064938 > > Nice work Alberto. I appreciate that you persevered and added a Dockerized test that exhibits your achievements. > > I wonder if you'd be willing to write something up to contribute to Geode documentation about this use case. Other people could benefit from knowing about this option. > > I do have a couple of minor changes that I'd like to see in the new acceptance test. > > Thanks @bschuchardt . I agree it would be good to write something in the documentation about this use case. I assume you are talking about WAN deployments in which the topology of the Geode cluster (the servers) is hidden behind a single IP address. Am I correct? > > If so, I will look for a place in the Geode documentation to add to it. I think it will be best to do it in a new PR. @bschuchardt I have created a new ticket GEODE-8738 and a PR #5766 with the information you suggested. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8737) Create new geode example for about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236056#comment-17236056 ] ASF GitHub Bot commented on GEODE-8737: --- yrashish opened a new pull request #104: URL: https://github.com/apache/geode-examples/pull/104 created simple example for geode rest api. Kindly review and provide feedback. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create new geode example for about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8737) Create new geode example for about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8737: -- Labels: pull-request-available (was: ) > Create new geode example for about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > Labels: pull-request-available > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8737) Create new geode example for about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236061#comment-17236061 ] ASF GitHub Bot commented on GEODE-8737: --- lgtm-com[bot] commented on pull request #104: URL: https://github.com/apache/geode-examples/pull/104#issuecomment-731098260 This pull request **introduces 1 alert** when merging a13ca6abd1a18351aece9bf5656262688deac4cb into 3362a4541bb00884fd3036bb74f36a2afc518713 - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-examples/rev/pr-f603c7b63a3b607ed04e968d68442e2911915cce) **new alerts:** * 1 for Potential input resource leak This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create new geode example for about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > Labels: pull-request-available > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8737) Create new geode example about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Choudhary updated GEODE-8737: Summary: Create new geode example about rest api (was: Create new geode example for about rest api) > Create new geode example about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > Labels: pull-request-available > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236186#comment-17236186 ] ASF GitHub Bot commented on GEODE-8732: --- sabbey37 merged pull request #5762: URL: https://github.com/apache/geode/pull/5762 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8732: --- Priority: Minor (was: Major) > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey reassigned GEODE-8732: -- Assignee: Sarah Abbey > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236188#comment-17236188 ] ASF subversion and git services commented on GEODE-8732: Commit 49e47004b8a7b948f6d44e1002cfbdb0d67f0f12 in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=49e4700 ] GEODE-8732: Update Tomcat9 module to publish to Maven (#5762) > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8732. Fix Version/s: 1.14.0 Resolution: Fixed > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236257#comment-17236257 ] ASF GitHub Bot commented on GEODE-8717: --- ringles opened a new pull request #5767: URL: https://github.com/apache/geode/pull/5767 Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ X] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ X] Is your initial contribution a single, squashed commit? - [ X] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8717: -- Labels: pull-request-available (was: ) > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[
https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236271#comment-17236271
]
ASF GitHub Bot commented on GEODE-8521:
---
bschuchardt commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r527801127
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImpl.java
##
@@ -96,39 +98,60 @@ public void updateThreadStatus() {
@Override
public boolean startMonitor(Mode mode) {
-AbstractExecutor absExtgroup;
+return startMonitoring(createAbstractExecutor(mode));
+ }
+
+ @Override
+ public void endMonitor() {
+this.monitorMap.remove(Thread.currentThread().getId());
+ }
+
+ @VisibleForTesting
+ boolean isMonitoring() {
+return monitorMap.containsKey(Thread.currentThread().getId());
+ }
+
+ @Override
+ public AbstractExecutor createAbstractExecutor(Mode mode) {
switch (mode) {
case FunctionExecutor:
-absExtgroup = new FunctionExecutionPooledExecutorGroup(this);
-break;
+return new FunctionExecutionPooledExecutorGroup();
case PooledExecutor:
-absExtgroup = new PooledExecutorGroup(this);
-break;
+return new PooledExecutorGroup();
case SerialQueuedExecutor:
-absExtgroup = new SerialQueuedExecutorGroup(this);
-break;
+return new SerialQueuedExecutorGroup();
case OneTaskOnlyExecutor:
-absExtgroup = new OneTaskOnlyExecutorGroup(this);
-break;
+return new OneTaskOnlyExecutorGroup();
case ScheduledThreadExecutor:
-absExtgroup = new ScheduledThreadPoolExecutorWKAGroup(this);
-break;
+return new ScheduledThreadPoolExecutorWKAGroup();
case AGSExecutor:
-absExtgroup = new GatewaySenderEventProcessorGroup(this);
-break;
+return new GatewaySenderEventProcessorGroup();
+ case P2PReaderExecutor:
+return new P2PReaderExecutorGroup();
default:
-return false;
+throw new IllegalStateException("Unhandled mode=" + mode);
}
-this.monitorMap.put(Thread.currentThread().getId(), absExtgroup);
+ }
+
+ @Override
+ public boolean startMonitoring(AbstractExecutor executor) {
+executor.setStartTime(System.currentTimeMillis());
Review comment:
I'm a little concerned about the impact of taking yet another
millisecond clock reading on every message that we dispatch. This should be
run through extensive performance testing before merging it to develop.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add P2P message reader threads to thread monitoring
> ---
>
> Key: GEODE-8521
> URL: https://issues.apache.org/jira/browse/GEODE-8521
> Project: Geode
> Issue Type: Wish
> Components: messaging
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Add P2P message reader threads to thread monitoring to help with identifying
> stuck P2P message readers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8637) Configure Gradle to run each test worker in a unique working directory
[ https://issues.apache.org/jira/browse/GEODE-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery resolved GEODE-8637. --- Resolution: Fixed > Configure Gradle to run each test worker in a unique working directory > -- > > Key: GEODE-8637 > URL: https://issues.apache.org/jira/browse/GEODE-8637 > Project: Geode > Issue Type: Test > Components: build, tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > For these test tasks, configure Gradle to run each test worker in a unique > working dir: > * acceptanceTest > * distributedTest > * integrationTest > * uiTest > * upgradeTest > * All repeat*Test tasks > These tasks run tests that might write files to disk. Giving each test worker > a unique directory allows these tests to run concurrently without interfering > with each other's files and directories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8637) Configure Gradle to run each test worker in a unique working directory
[ https://issues.apache.org/jira/browse/GEODE-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery updated GEODE-8637: -- Fix Version/s: 1.14.0 > Configure Gradle to run each test worker in a unique working directory > -- > > Key: GEODE-8637 > URL: https://issues.apache.org/jira/browse/GEODE-8637 > Project: Geode > Issue Type: Test > Components: build, tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > For these test tasks, configure Gradle to run each test worker in a unique > working dir: > * acceptanceTest > * distributedTest > * integrationTest > * uiTest > * upgradeTest > * All repeat*Test tasks > These tasks run tests that might write files to disk. Giving each test worker > a unique directory allows these tests to run concurrently without interfering > with each other's files and directories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8637) Configure Gradle to run each test worker in a unique working directory
[ https://issues.apache.org/jira/browse/GEODE-8637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dale Emery closed GEODE-8637. - > Configure Gradle to run each test worker in a unique working directory > -- > > Key: GEODE-8637 > URL: https://issues.apache.org/jira/browse/GEODE-8637 > Project: Geode > Issue Type: Test > Components: build, tests >Affects Versions: 1.14.0 >Reporter: Dale Emery >Assignee: Dale Emery >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.14.0 > > > For these test tasks, configure Gradle to run each test worker in a unique > working dir: > * acceptanceTest > * distributedTest > * integrationTest > * uiTest > * upgradeTest > * All repeat*Test tasks > These tasks run tests that might write files to disk. Giving each test worker > a unique directory allows these tests to run concurrently without interfering > with each other's files and directories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[
https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236312#comment-17236312
]
ASF GitHub Bot commented on GEODE-8521:
---
dschneider-pivotal commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r527838255
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImpl.java
##
@@ -96,39 +98,60 @@ public void updateThreadStatus() {
@Override
public boolean startMonitor(Mode mode) {
-AbstractExecutor absExtgroup;
+return startMonitoring(createAbstractExecutor(mode));
+ }
+
+ @Override
+ public void endMonitor() {
+this.monitorMap.remove(Thread.currentThread().getId());
+ }
+
+ @VisibleForTesting
+ boolean isMonitoring() {
+return monitorMap.containsKey(Thread.currentThread().getId());
+ }
+
+ @Override
+ public AbstractExecutor createAbstractExecutor(Mode mode) {
switch (mode) {
case FunctionExecutor:
-absExtgroup = new FunctionExecutionPooledExecutorGroup(this);
-break;
+return new FunctionExecutionPooledExecutorGroup();
case PooledExecutor:
-absExtgroup = new PooledExecutorGroup(this);
-break;
+return new PooledExecutorGroup();
case SerialQueuedExecutor:
-absExtgroup = new SerialQueuedExecutorGroup(this);
-break;
+return new SerialQueuedExecutorGroup();
case OneTaskOnlyExecutor:
-absExtgroup = new OneTaskOnlyExecutorGroup(this);
-break;
+return new OneTaskOnlyExecutorGroup();
case ScheduledThreadExecutor:
-absExtgroup = new ScheduledThreadPoolExecutorWKAGroup(this);
-break;
+return new ScheduledThreadPoolExecutorWKAGroup();
case AGSExecutor:
-absExtgroup = new GatewaySenderEventProcessorGroup(this);
-break;
+return new GatewaySenderEventProcessorGroup();
+ case P2PReaderExecutor:
+return new P2PReaderExecutorGroup();
default:
-return false;
+throw new IllegalStateException("Unhandled mode=" + mode);
}
-this.monitorMap.put(Thread.currentThread().getId(), absExtgroup);
+ }
+
+ @Override
+ public boolean startMonitoring(AbstractExecutor executor) {
+executor.setStartTime(System.currentTimeMillis());
Review comment:
I had the same thought. I was even concerned about constantly adding and
removing from the concurrent map. We could just use the frequency of the
monitor thread to do the time work. For example if it finds an AbstractExecutor
in the map that it has not seen before then the monitor thread could set the
time it first saw it. If later monitor samples see it again it could use this
time (i.e. the one the monitor set) to determine if it is stuck. This could
even be done without timestamps. Just a simple counter the monitor incs and the
p2p reader thread clears. If the monitor thread is waking up at a fixed
interval then you know the thread has been stuck for at least that much time. I
like your idea of having custom code in P2PReaderExecutorGroup for this. When I
was thinking about it I thought I would need to change the behavior of all the
existing threads being monitored. Thanks for the feedback!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add P2P message reader threads to thread monitoring
> ---
>
> Key: GEODE-8521
> URL: https://issues.apache.org/jira/browse/GEODE-8521
> Project: Geode
> Issue Type: Wish
> Components: messaging
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Add P2P message reader threads to thread monitoring to help with identifying
> stuck P2P message readers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[
https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236321#comment-17236321
]
ASF GitHub Bot commented on GEODE-8717:
---
jdeppe-pivotal commented on a change in pull request #5767:
URL: https://github.com/apache/geode/pull/5767#discussion_r527844246
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractInfoIntegrationTest.java
##
@@ -98,71 +165,115 @@ public void shouldReturnClusterEnabledProperty() {
assertThat(actualResult).contains(expectedResult);
}
- final List SERVER_PROPERTIES =
- Arrays.asList(
- "# Server",
- "redis_version:",
- "tcp_port:",
- "redis_mode:");
-
- final List PERSISTENCE_PROPERTIES =
- Arrays.asList(
- "# Persistence",
- "loading:");
-
- final List CLUSTER_PROPERTIES =
- Arrays.asList(
- "# Cluster",
- "cluster_enabled:");
-
@Test
- public void shouldReturnServerSectionsGivenServerSectionParameter() {
+ public void shouldReturnServerSections_givenServerSectionParameter() {
+List nonServerProperties = ALL_PROPERTIES;
+nonServerProperties.removeAll(SERVER_PROPERTIES);
+
String actualResult = jedis.info("server");
assertThat(actualResult).contains(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonServerProperties);
}
@Test
- public void shouldReturnClusterSectionsGivenClusterSectionParameter() {
+ public void shouldReturnClusterSections_givenClusterSectionParameter() {
+List nonClusterProperties = ALL_PROPERTIES;
+nonClusterProperties.removeAll(CLUSTER_PROPERTIES);
+
String actualResult = jedis.info("cluster");
assertThat(actualResult).contains(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonClusterProperties);
}
@Test
- public void
shouldReturnPersistenceSectionsGivenPersistenceSectionParameter() {
+ public void
shouldReturnPersistenceSections_givenPersistenceSectionParameter() {
+List nonPersistenceProperties = ALL_PROPERTIES;
+nonPersistenceProperties.removeAll(PERSISTENCE_PROPERTIES);
+
String actualResult = jedis.info("persistence");
assertThat(actualResult).contains(PERSISTENCE_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonPersistenceProperties);
+ }
+
+ @Test
+ public void shouldReturnStatsSections_givenStatsSectionParameter() {
+List nonStatsProperties = ALL_PROPERTIES;
+nonStatsProperties.removeAll(STATS_PROPERTIES);
Review comment:
This is going to also modify `ALL_PROPERTIES` since `nonStatsProperties`
is just a reference. I'd suggest making `ALL_PROPERTIES` immuntable with
something like
```
.collect(Collectors.collectingAndThen(Collectors.toList(),
Collections::unmodifiableList));
```
and then it would be evident that you need to make a copy here and other
places where this is happening.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis INFO Command should only return specified sections when given parameter
> -
>
> Key: GEODE-8717
> URL: https://issues.apache.org/jira/browse/GEODE-8717
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.14.0
>Reporter: John Hutchison
>Assignee: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://github.com/apache/geode/pull/5756
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[
https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236322#comment-17236322
]
ASF GitHub Bot commented on GEODE-8717:
---
jdeppe-pivotal commented on a change in pull request #5767:
URL: https://github.com/apache/geode/pull/5767#discussion_r527844246
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractInfoIntegrationTest.java
##
@@ -98,71 +165,115 @@ public void shouldReturnClusterEnabledProperty() {
assertThat(actualResult).contains(expectedResult);
}
- final List SERVER_PROPERTIES =
- Arrays.asList(
- "# Server",
- "redis_version:",
- "tcp_port:",
- "redis_mode:");
-
- final List PERSISTENCE_PROPERTIES =
- Arrays.asList(
- "# Persistence",
- "loading:");
-
- final List CLUSTER_PROPERTIES =
- Arrays.asList(
- "# Cluster",
- "cluster_enabled:");
-
@Test
- public void shouldReturnServerSectionsGivenServerSectionParameter() {
+ public void shouldReturnServerSections_givenServerSectionParameter() {
+List nonServerProperties = ALL_PROPERTIES;
+nonServerProperties.removeAll(SERVER_PROPERTIES);
+
String actualResult = jedis.info("server");
assertThat(actualResult).contains(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonServerProperties);
}
@Test
- public void shouldReturnClusterSectionsGivenClusterSectionParameter() {
+ public void shouldReturnClusterSections_givenClusterSectionParameter() {
+List nonClusterProperties = ALL_PROPERTIES;
+nonClusterProperties.removeAll(CLUSTER_PROPERTIES);
+
String actualResult = jedis.info("cluster");
assertThat(actualResult).contains(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonClusterProperties);
}
@Test
- public void
shouldReturnPersistenceSectionsGivenPersistenceSectionParameter() {
+ public void
shouldReturnPersistenceSections_givenPersistenceSectionParameter() {
+List nonPersistenceProperties = ALL_PROPERTIES;
+nonPersistenceProperties.removeAll(PERSISTENCE_PROPERTIES);
+
String actualResult = jedis.info("persistence");
assertThat(actualResult).contains(PERSISTENCE_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonPersistenceProperties);
+ }
+
+ @Test
+ public void shouldReturnStatsSections_givenStatsSectionParameter() {
+List nonStatsProperties = ALL_PROPERTIES;
+nonStatsProperties.removeAll(STATS_PROPERTIES);
Review comment:
This is going to also modify `ALL_PROPERTIES` since `nonStatsProperties`
is just a reference. I'd suggest making `ALL_PROPERTIES` immutable with
something like
```
.collect(Collectors.collectingAndThen(Collectors.toList(),
Collections::unmodifiableList));
```
and then it would be evident that you need to make a copy here and other
places where this is happening.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis INFO Command should only return specified sections when given parameter
> -
>
> Key: GEODE-8717
> URL: https://issues.apache.org/jira/browse/GEODE-8717
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.14.0
>Reporter: John Hutchison
>Assignee: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://github.com/apache/geode/pull/5756
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[
https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236330#comment-17236330
]
ASF GitHub Bot commented on GEODE-8521:
---
dschneider-pivotal commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r527859411
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImpl.java
##
@@ -96,39 +98,60 @@ public void updateThreadStatus() {
@Override
public boolean startMonitor(Mode mode) {
-AbstractExecutor absExtgroup;
+return startMonitoring(createAbstractExecutor(mode));
+ }
+
+ @Override
+ public void endMonitor() {
+this.monitorMap.remove(Thread.currentThread().getId());
+ }
+
+ @VisibleForTesting
+ boolean isMonitoring() {
+return monitorMap.containsKey(Thread.currentThread().getId());
+ }
+
+ @Override
+ public AbstractExecutor createAbstractExecutor(Mode mode) {
switch (mode) {
case FunctionExecutor:
-absExtgroup = new FunctionExecutionPooledExecutorGroup(this);
-break;
+return new FunctionExecutionPooledExecutorGroup();
case PooledExecutor:
-absExtgroup = new PooledExecutorGroup(this);
-break;
+return new PooledExecutorGroup();
case SerialQueuedExecutor:
-absExtgroup = new SerialQueuedExecutorGroup(this);
-break;
+return new SerialQueuedExecutorGroup();
case OneTaskOnlyExecutor:
-absExtgroup = new OneTaskOnlyExecutorGroup(this);
-break;
+return new OneTaskOnlyExecutorGroup();
case ScheduledThreadExecutor:
-absExtgroup = new ScheduledThreadPoolExecutorWKAGroup(this);
-break;
+return new ScheduledThreadPoolExecutorWKAGroup();
case AGSExecutor:
-absExtgroup = new GatewaySenderEventProcessorGroup(this);
-break;
+return new GatewaySenderEventProcessorGroup();
+ case P2PReaderExecutor:
+return new P2PReaderExecutorGroup();
default:
-return false;
+throw new IllegalStateException("Unhandled mode=" + mode);
}
-this.monitorMap.put(Thread.currentThread().getId(), absExtgroup);
+ }
+
+ @Override
+ public boolean startMonitoring(AbstractExecutor executor) {
+executor.setStartTime(System.currentTimeMillis());
Review comment:
I converted back to draft mode. Will rework this and submit it again.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add P2P message reader threads to thread monitoring
> ---
>
> Key: GEODE-8521
> URL: https://issues.apache.org/jira/browse/GEODE-8521
> Project: Geode
> Issue Type: Wish
> Components: messaging
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Add P2P message reader threads to thread monitoring to help with identifying
> stuck P2P message readers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8573) SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
[
https://issues.apache.org/jira/browse/GEODE-8573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236338#comment-17236338
]
Geode Integration commented on GEODE-8573:
--
Seen in [DistributedTestOpenJDK11
#610|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/610]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0503/test-results/distributedTest/1605891132/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0503/test-artifacts/1605891132/distributedtestfiles-OpenJDK11-1.14.0-build.0503.tgz].
> SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting
>
>
> Key: GEODE-8573
> URL: https://issues.apache.org/jira/browse/GEODE-8573
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.14.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/521]
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> > testRestartSerialGatewaySendersWhilePutting[1: numDispatchers=3] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest$$Lambda$356/426344166.run
> in VM 5 running on Host 538fd3213f62 with 8 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.testRestartSerialGatewaySendersWhilePutting(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest
> that uses org.apache.geode.internal.cache.wan.InternalGatewaySender,
> org.apache.geode.internal.cache.wan.InternalGatewaySenderint [Sender
> statistics unprocessed event map size] expected:<[0]> but was:<[3]> within 5
> minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.validateSecondaryQueueSizeStat(SerialGatewaySenderOperationsDistributedTest.java:1216)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$testRestartSerialGatewaySendersWhilePutting$bb17a952$23(SerialGatewaySenderOperationsDistributedTest.java:407)
> Caused by:
> org.junit.ComparisonFailure: [Sender statistics unprocessed event
> map size] expected:<[0]> but was:<[3]>
> at
> sun.reflect.GeneratedConstructorAccessor81.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderOperationsDistributedTest.lambda$validateSecondaryQueueSizeStat$8(SerialGatewaySenderOperationsDistributedTest.java:1219)
> {noformat}
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-results/distributedTest/1601774166/]
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0389/test-artifacts/1601774166/distributedtestfiles-OpenJDK8-1.14.0-build.0389.tgz]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236340#comment-17236340
]
Geode Integration commented on GEODE-7489:
--
Seen in [IntegrationTestOpenJDK8
#584|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/584]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0503/test-results/integrationTest/1605884707/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0503/test-artifacts/1605884707/integrationtestfiles-OpenJDK8-1.14.0-build.0503.tgz].
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[
https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236352#comment-17236352
]
ASF GitHub Bot commented on GEODE-8717:
---
ringles commented on a change in pull request #5767:
URL: https://github.com/apache/geode/pull/5767#discussion_r527885873
##
File path:
geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractInfoIntegrationTest.java
##
@@ -98,71 +165,115 @@ public void shouldReturnClusterEnabledProperty() {
assertThat(actualResult).contains(expectedResult);
}
- final List SERVER_PROPERTIES =
- Arrays.asList(
- "# Server",
- "redis_version:",
- "tcp_port:",
- "redis_mode:");
-
- final List PERSISTENCE_PROPERTIES =
- Arrays.asList(
- "# Persistence",
- "loading:");
-
- final List CLUSTER_PROPERTIES =
- Arrays.asList(
- "# Cluster",
- "cluster_enabled:");
-
@Test
- public void shouldReturnServerSectionsGivenServerSectionParameter() {
+ public void shouldReturnServerSections_givenServerSectionParameter() {
+List nonServerProperties = ALL_PROPERTIES;
+nonServerProperties.removeAll(SERVER_PROPERTIES);
+
String actualResult = jedis.info("server");
assertThat(actualResult).contains(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonServerProperties);
}
@Test
- public void shouldReturnClusterSectionsGivenClusterSectionParameter() {
+ public void shouldReturnClusterSections_givenClusterSectionParameter() {
+List nonClusterProperties = ALL_PROPERTIES;
+nonClusterProperties.removeAll(CLUSTER_PROPERTIES);
+
String actualResult = jedis.info("cluster");
assertThat(actualResult).contains(CLUSTER_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(PERSISTENCE_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonClusterProperties);
}
@Test
- public void
shouldReturnPersistenceSectionsGivenPersistenceSectionParameter() {
+ public void
shouldReturnPersistenceSections_givenPersistenceSectionParameter() {
+List nonPersistenceProperties = ALL_PROPERTIES;
+nonPersistenceProperties.removeAll(PERSISTENCE_PROPERTIES);
+
String actualResult = jedis.info("persistence");
assertThat(actualResult).contains(PERSISTENCE_PROPERTIES);
-assertThat(actualResult).doesNotContain(SERVER_PROPERTIES);
-assertThat(actualResult).doesNotContain(CLUSTER_PROPERTIES);
+assertThat(actualResult).doesNotContain(nonPersistenceProperties);
+ }
+
+ @Test
+ public void shouldReturnStatsSections_givenStatsSectionParameter() {
+List nonStatsProperties = ALL_PROPERTIES;
+nonStatsProperties.removeAll(STATS_PROPERTIES);
Review comment:
Done!
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Redis INFO Command should only return specified sections when given parameter
> -
>
> Key: GEODE-8717
> URL: https://issues.apache.org/jira/browse/GEODE-8717
> Project: Geode
> Issue Type: Improvement
> Components: redis
>Affects Versions: 1.14.0
>Reporter: John Hutchison
>Assignee: Raymond Ingles
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> https://github.com/apache/geode/pull/5756
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236360#comment-17236360
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527892343
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,101 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+import org.apache.geode.annotations.VisibleForTesting;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Timer {
+long nanoTime();
+
+void sleep(long sleepTimeInNano) throws InterruptedException;
+ }
+
+ static class SteadyTimer implements Timer {
+@Override
+public long nanoTime() {
+ return System.nanoTime();
+}
+
+@Override
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ long millis = NANOSECONDS.toMillis(sleepTimeInNano);
+ // avoid throwing IllegalArgumentException
+ if (millis > 0) {
+Thread.sleep(millis);
+ }
+}
+ }
+
+ private static final SteadyTimer steadyClock = new SteadyTimer();
+
+ /**
+ * Try the supplier function until the predicate is true or timeout occurs.
+ *
+ * @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
+ * @param interval time between each try
+ * @param intervalUnit the unit for interval
+ * @param supplier to execute until predicate is true or times out
+ * @param predicate to test for retry
+ * @param type of return value
+ * @return value from supplier after it passes predicate or times out.
+ */
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate) throws TimeoutException, InterruptedException {
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
+ }
+
+ @VisibleForTesting
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate,
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
+long intervalNano = NANOSECONDS.convert(interval, intervalUnit);
+
+T value;
+for (;;) {
+ value = supplier.get();
+ if (predicate.test(value)) {
+return value;
+ } else {
+// if there is still more time left after we sleep for interval
period, then sleep and retry
+// otherwise break out and throw TimeoutException
+if ((timer.nanoTime() + intervalNano) < until) {
Review comment:
There is no need to sleep for the full interval (`intervalNano`) if
`until - timer.nanoTime()` is smaller.
I recommend (again), as have others, that the code sleep for the minimum
time required. We understand that `Thread.sleep()` does not make real-time
guarantees. Nevertheless, this code would be more robust and accurate if it was
coded that way.
Something like this:
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236362#comment-17236362
]
ASF GitHub Bot commented on GEODE-8623:
---
Bill commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527895103
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,101 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+import org.apache.geode.annotations.VisibleForTesting;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Timer {
+long nanoTime();
+
+void sleep(long sleepTimeInNano) throws InterruptedException;
Review comment:
By making `sleep()` take nanosecond units, every implementation (like
the one below) has to make the conversion and handle any problems.
I recommend making this method take millisecond units since that's what
`Thread.sleep()` takes. This simplifies every implementation, and, perhaps more
importantly, moves the error-handling logic up into the `tryFor()` method,
making that method more robust.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local hostname caching. If it fails to resolve the local hostname when
> loading the caching utility class then any service dependent on this name
> will fail without chance for recovery.
> {code}
> [error 2020/09/30 19:50:21.644 UTC tid=0x1] Jmx manager could not be
> started because java.net.UnknownHostException
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:133)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:432)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:181)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:127)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2063)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:606)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1239)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:219)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:171)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distri
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[
https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236382#comment-17236382
]
ASF GitHub Bot commented on GEODE-8521:
---
bschuchardt commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r527913185
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImpl.java
##
@@ -96,39 +98,60 @@ public void updateThreadStatus() {
@Override
public boolean startMonitor(Mode mode) {
-AbstractExecutor absExtgroup;
+return startMonitoring(createAbstractExecutor(mode));
+ }
+
+ @Override
+ public void endMonitor() {
+this.monitorMap.remove(Thread.currentThread().getId());
+ }
+
+ @VisibleForTesting
+ boolean isMonitoring() {
+return monitorMap.containsKey(Thread.currentThread().getId());
+ }
+
+ @Override
+ public AbstractExecutor createAbstractExecutor(Mode mode) {
switch (mode) {
case FunctionExecutor:
-absExtgroup = new FunctionExecutionPooledExecutorGroup(this);
-break;
+return new FunctionExecutionPooledExecutorGroup();
case PooledExecutor:
-absExtgroup = new PooledExecutorGroup(this);
-break;
+return new PooledExecutorGroup();
case SerialQueuedExecutor:
-absExtgroup = new SerialQueuedExecutorGroup(this);
-break;
+return new SerialQueuedExecutorGroup();
case OneTaskOnlyExecutor:
-absExtgroup = new OneTaskOnlyExecutorGroup(this);
-break;
+return new OneTaskOnlyExecutorGroup();
case ScheduledThreadExecutor:
-absExtgroup = new ScheduledThreadPoolExecutorWKAGroup(this);
-break;
+return new ScheduledThreadPoolExecutorWKAGroup();
case AGSExecutor:
-absExtgroup = new GatewaySenderEventProcessorGroup(this);
-break;
+return new GatewaySenderEventProcessorGroup();
+ case P2PReaderExecutor:
+return new P2PReaderExecutorGroup();
default:
-return false;
+throw new IllegalStateException("Unhandled mode=" + mode);
}
-this.monitorMap.put(Thread.currentThread().getId(), absExtgroup);
+ }
+
+ @Override
+ public boolean startMonitoring(AbstractExecutor executor) {
+executor.setStartTime(System.currentTimeMillis());
Review comment:
having the monitor thread set the time is a good idea. Another thing
you could do is have the Monitor thread record the current time when it wakes
up and use that for new entries in the map. GMSHealthMonitor's monitor thread
does something like that.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add P2P message reader threads to thread monitoring
> ---
>
> Key: GEODE-8521
> URL: https://issues.apache.org/jira/browse/GEODE-8521
> Project: Geode
> Issue Type: Wish
> Components: messaging
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Add P2P message reader threads to thread monitoring to help with identifying
> stuck P2P message readers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
Jason Huynh created GEODE-8739: -- Summary: Split brain when locators exhaust join attempts on non existant servers Key: GEODE-8739 URL: https://issues.apache.org/jira/browse/GEODE-8739 Project: Geode Issue Type: Bug Components: membership Reporter: Jason Huynh The hypothesis: "if there is a locator view .dat file with several non-existent servers then then locators will waste all of their join attempts on the servers instead of finding each other" Scenario is a test/user attempts to recreate a cluster with existing .dat and persistent files. The locators are spun in parallel and from the analysis, it looks like they are able to communicate with each other, but then end up forming their own ds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[ https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh updated GEODE-8739: --- Attachment: exportedLogs_locator-1.zip exportedLogs_locator-0.zip > Split brain when locators exhaust join attempts on non existant servers > --- > > Key: GEODE-8739 > URL: https://issues.apache.org/jira/browse/GEODE-8739 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jason Huynh >Priority: Major > Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip > > > The hypothesis: "if there is a locator view .dat file with several > non-existent servers then then locators will waste all of their join attempts > on the servers instead of finding each other" > Scenario is a test/user attempts to recreate a cluster with existing .dat and > persistent files. The locators are spun in parallel and from the analysis, > it looks like they are able to communicate with each other, but then end up > forming their own ds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-7489:
--
Labels: pull-request-available (was: )
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236396#comment-17236396
]
ASF GitHub Bot commented on GEODE-7489:
---
bschuchardt opened a new pull request #5768:
URL: https://github.com/apache/geode/pull/5768
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236426#comment-17236426 ] ASF subversion and git services commented on GEODE-8725: Commit 5bf66742157b0195df1f4f01923a9000d3ea323c in geode's branch refs/heads/support/1.13 from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5bf6674 ] GEODE-8725: Bump jetty from 9.4.33.v20201020 to 9.4.34.v20201102 > Update Jetty to 9.4.34 > -- > > Key: GEODE-8725 > URL: https://issues.apache.org/jira/browse/GEODE-8725 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > Update Jetty to latest version (9.4.34) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236430#comment-17236430 ] ASF subversion and git services commented on GEODE-8725: Commit 1d0cd586730ce094caae2a574f2660873994ad86 in geode's branch refs/heads/support/1.12 from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1d0cd58 ] GEODE-8725: Bump jetty from 9.4.33.v20201020 to 9.4.34.v20201102 > Update Jetty to 9.4.34 > -- > > Key: GEODE-8725 > URL: https://issues.apache.org/jira/browse/GEODE-8725 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Assignee: Sarah Abbey >Priority: Minor > Labels: pull-request-available > Fix For: 1.14.0 > > > Update Jetty to latest version (9.4.34) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[
https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236435#comment-17236435
]
Bill Burcham commented on GEODE-8739:
-
I believe the Geode processes in question were running inside Kubernetes (pods.)
The purpose of the (persistent view) {{.dat}} files are to enable a locator
(process) re-started on a particular host, to re-join a distributed system
(cluster). The assumption is that the distributed system has had continuity
across the locator's restart, i.e. the assumption is that the cluster still
exists.
If you want to do a Kubernetes maintenance operation that kills an entire Geode
distributed system and starts up a new on in its place, you should probably
make sure no {{.dat}} files are visible to the (new) locator processes.
Alternately, in a use-case where a locator process (running inside a pod)
crashes (the pod crashes) and a new pod is started that is "logically" the same
one, it is TBD.
> Split brain when locators exhaust join attempts on non existant servers
> ---
>
> Key: GEODE-8739
> URL: https://issues.apache.org/jira/browse/GEODE-8739
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Jason Huynh
>Priority: Major
> Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip
>
>
> The hypothesis: "if there is a locator view .dat file with several
> non-existent servers then then locators will waste all of their join attempts
> on the servers instead of finding each other"
> Scenario is a test/user attempts to recreate a cluster with existing .dat and
> persistent files. The locators are spun in parallel and from the analysis,
> it looks like they are able to communicate with each other, but then end up
> forming their own ds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[ https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236457#comment-17236457 ] Jason Huynh commented on GEODE-8739: yes, these processes happen to have run in Kubernetes. We still think it can occur with processes not being run in kubernetes but will prove it out in a test and update the ticket accordingly. So if we happen to have the same scenario on bare metal, we expect this to not split? or are we saying that we expect the admin to delete the .dat file before starting up? > Split brain when locators exhaust join attempts on non existant servers > --- > > Key: GEODE-8739 > URL: https://issues.apache.org/jira/browse/GEODE-8739 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jason Huynh >Priority: Major > Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip > > > The hypothesis: "if there is a locator view .dat file with several > non-existent servers then then locators will waste all of their join attempts > on the servers instead of finding each other" > Scenario is a test/user attempts to recreate a cluster with existing .dat and > persistent files. The locators are spun in parallel and from the analysis, > it looks like they are able to communicate with each other, but then end up > forming their own ds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236462#comment-17236462
]
ASF GitHub Bot commented on GEODE-7489:
---
bschuchardt merged pull request #5768:
URL: https://github.com/apache/geode/pull/5768
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7489) DistributionArchUnitTest is running out of memory for some users
[
https://issues.apache.org/jira/browse/GEODE-7489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236463#comment-17236463
]
ASF subversion and git services commented on GEODE-7489:
Commit 986733ecb27cfb959bccf080a1dee77981dc458a in geode's branch
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=986733e ]
GEODE-7489: Disable DistributionArchUnitTest (#5768)
> DistributionArchUnitTest is running out of memory for some users
>
>
> Key: GEODE-7489
> URL: https://issues.apache.org/jira/browse/GEODE-7489
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test ran out of memory when running ./gradlew build for some users. From
> the mailing list:
> {noformat}
> Any ideas why DistributionArchUnitTest would run OutOfMemoryError when
> doing a "./gradlew build"?
> I think we should move any unit tests that run OutOfMemoryError out of unit
> tests (to integration tests maybe?).
> > Task :geode:geode-core:test
> Heap dump file created [957877145 bytes in 17.227 secs]
> org.apache.geode.distributed.internal.DistributionArchUnitTest >
> classMethod FAILED
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> 6991 tests completed, 1 failed, 12 skipped
> {noformat}
> This is a relatively new test that is scanning a lot of classes for
> dependencies, so it may have memory issues.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8738) Document how to Configure just one IP address and port to access all gateway receivers in a site
[ https://issues.apache.org/jira/browse/GEODE-8738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236480#comment-17236480 ] ASF GitHub Bot commented on GEODE-8738: --- davebarnes97 commented on pull request #5766: URL: https://github.com/apache/geode/pull/5766#issuecomment-731438229 @albertogpz Thank you for your contribution. I have edited your text for format and style, but I am unable to push my changes to your fork. I attach the file here so you can incorporate my changes from your side. Please let me know if you'd like to receive these changes in another way. Best regards, and thanks! [GEODE-8738-edit.zip](https://github.com/apache/geode/files/5576363/GEODE-8738-edit.zip) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Document how to Configure just one IP address and port to access all gateway > receivers in a site > > > Key: GEODE-8738 > URL: https://issues.apache.org/jira/browse/GEODE-8738 > Project: Geode > Issue Type: Improvement > Components: docs, wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > The aim of this ticket is provide information in the Geode documentation on > how to configure WAN deployments in which the gateway receivers are hidden > behind the same IP address and port after some improvements and fixes have > been implemented in Geode (GEODE-8656, GEODE-7565). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[
https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236482#comment-17236482
]
Dan Smith commented on GEODE-8739:
--
These are what are the most interesting lines from the logs files I think,
where the locators each decide that they should be the coordinator.
What's weird is that in the "Discovery state" message, each one has the same
list of registrants, and the same view. But they have different possible
coordinators.
{noformat}
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:12.973 GMT
tid=0x1] using findCoordinatorFromView
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:12.974 GMT
tid=0x1] searching for coordinator in findCoordinatorFromView
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:12.974 GMT
tid=0x1] sending FindCoordinatorRequests to
[192.168.68.28(gemfirecluster-sample-server-0:1):41000,
192.168.149.18(gemfirecluster-sample-server-1:1):41000,
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000]
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:15.975 GMT
tid=0x1] findCoordinatorFromView processing
FindCoordinatorResponse(coordinator=192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000;
senderId=192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000)
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:15.976 GMT
tid=0x1] Discovery state after looking for membership coordinator is
locatorsContacted=2; findInViewResponses=0;
alreadyTried=[192.168.149.18(gemfirecluster-sample-server-1:1):41000,
192.168.68.28(gemfirecluster-sample-server-0:1):41000,
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000];
registrants=[192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000,
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000];
possibleCoordinator=192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000;
viewId=-1; hasContactedAJoinedLocator=false;
view=View[192.168.149.10(gemfirecluster-sample-locator-0:1:locator):41000|-1]
members: [192.168.68.28(gemfirecluster-sample-server-0:1):41000{lead},
192.168.149.18(gemfirecluster-sample-server-1:1):41000]; responses=[]
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:15.976 GMT
tid=0x1] found possible coordinator
192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000
gemfirecluster-sample-locator-0.log: [info 2020/11/17 12:22:15.976 GMT
tid=0x1] This member is becoming the membership coordinator with address
192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:16.000 GMT
tid=0x1] using findCoordinatorFromView
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:16.001 GMT
tid=0x1] searching for coordinator in findCoordinatorFromView
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:16.002 GMT
tid=0x1] sending FindCoordinatorRequests to
[192.168.68.28(gemfirecluster-sample-server-0:1):41000,
192.168.149.18(gemfirecluster-sample-server-1:1):41000,
192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000]
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:19.003 GMT
tid=0x1] findCoordinatorFromView processing
FindCoordinatorResponse(coordinator=192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000;
senderId=192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000)
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:19.004 GMT
tid=0x1] findCoordinatorFromView's best guess is now
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:19.005 GMT
tid=0x1] Discovery state after looking for membership coordinator is
locatorsContacted=2; findInViewResponses=0;
alreadyTried=[192.168.149.18(gemfirecluster-sample-server-1:1):41000,
192.168.68.28(gemfirecluster-sample-server-0:1):41000];
registrants=[192.168.64.210(gemfirecluster-sample-locator-0:1:locator):41000,
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000];
possibleCoordinator=192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000;
viewId=-1; hasContactedAJoinedLocator=false;
view=View[192.168.149.10(gemfirecluster-sample-locator-0:1:locator):41000|-1]
members: [192.168.68.28(gemfirecluster-sample-server-0:1):41000{lead},
192.168.149.18(gemfirecluster-sample-server-1:1):41000]; responses=[]
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:19.005 GMT
tid=0x1] found possible coordinator
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000
gemfirecluster-sample-locator-1.log: [info 2020/11/17 12:22:19.005 GMT
tid=0x1] This member is becoming the membership coordinator with address
192.168.149.63(gemfirecluster-sample-locator-1:1:locator):41000
{noformat}
> Split brain when locators exhaust join attempts on non existant s
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[
https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236486#comment-17236486
]
Dan Smith commented on GEODE-8739:
--
I think I see the problem. If we fall into *findCoordinatorFromView*, the
locator chooses *itself* as the best coordinator.
{code}
if (localAddress.preferredForCoordinator()) {
// it's possible that all other potential coordinators are gone
// and this new member must become the coordinator
bestGuessCoordinator = localAddress;
}
{code}
Even though it got a response from the other locator, because it already tried
it once and it was not the coordinator at the time, it ignores that response
{noformat}
if (!localAddress.equals(suggestedCoordinator)
&& !state.alreadyTried.contains(suggestedCoordinator)) {
{noformat}
The regular findCoordinator logic doesn't seem to do this, it's just in
findCoordinatorFromView. It looks like we only get into findCoordinatorFromView
if we recovered a view from a .dat file.
> Split brain when locators exhaust join attempts on non existant servers
> ---
>
> Key: GEODE-8739
> URL: https://issues.apache.org/jira/browse/GEODE-8739
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Jason Huynh
>Priority: Major
> Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip
>
>
> The hypothesis: "if there is a locator view .dat file with several
> non-existent servers then then locators will waste all of their join attempts
> on the servers instead of finding each other"
> Scenario is a test/user attempts to recreate a cluster with existing .dat and
> persistent files. The locators are spun in parallel and from the analysis,
> it looks like they are able to communicate with each other, but then end up
> forming their own ds.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8717) Redis INFO Command should only return specified sections when given parameter
[ https://issues.apache.org/jira/browse/GEODE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236492#comment-17236492 ] ASF GitHub Bot commented on GEODE-8717: --- kohlmu-pivotal commented on a change in pull request #5767: URL: https://github.com/apache/geode/pull/5767#discussion_r528011451 ## File path: geode-redis/src/integrationTest/java/org/apache/geode/redis/internal/executor/server/AbstractInfoIntegrationTest.java ## @@ -39,6 +44,71 @@ private static final int REDIS_CLIENT_TIMEOUT = Math.toIntExact(GeodeAwaitility.getTimeout().toMillis()); + final List SERVER_PROPERTIES = + Arrays.asList( + "# Server", + "redis_version:", + "redis_mode:", + "tcp_port:", + "uptime_in_days:", + "uptime_in_seconds:"); + + final List PERSISTENCE_PROPERTIES = + Arrays.asList( + "# Persistence", + "rdb_changes_since_last_save", + "rdb_last_save_time", + "loading:"); + + final List REPLICATION_PROPERTIES = + Arrays.asList( + "# Replication", + "role:", + "connected_slaves:"); + + final List CLUSTER_PROPERTIES = + Arrays.asList( + "# Cluster", + "cluster_enabled:"); + + final List CLIENTS_PROPERTIES = + Arrays.asList( + "# Clients", + "connected_clients:", + "blocked_clients:"); + + final List MEMORY_PROPERTIES = + Arrays.asList( + "# Memory", + "used_memory:", + "mem_fragmentation_ratio:"); + + final List KEYSPACE_PROPERTIES = + Arrays.asList( + "# Keyspace", + "db0:"); + + final List STATS_PROPERTIES = + Arrays.asList( + "# Stats", + "total_commands_processed:", + "instantaneous_ops_per_sec:", + "total_net_input_bytes:", + "instantaneous_input_kbps:", + "total_connections_received:", + "keyspace_hits:", + "keyspace_misses:", + "evicted_keys:", + "rejected_connections:"); + + + final List ALL_PROPERTIES = + Stream.of(SERVER_PROPERTIES, PERSISTENCE_PROPERTIES, CLUSTER_PROPERTIES, + MEMORY_PROPERTIES, CLIENTS_PROPERTIES, STATS_PROPERTIES, REPLICATION_PROPERTIES) + .flatMap(Collection::stream) + .collect( + Collectors.collectingAndThen(Collectors.toList(), Collections::unmodifiableList)); Review comment: Wow... this seems so hard compared to `list.addAll` This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Redis INFO Command should only return specified sections when given parameter > - > > Key: GEODE-8717 > URL: https://issues.apache.org/jira/browse/GEODE-8717 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: John Hutchison >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > https://github.com/apache/geode/pull/5756 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[
https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236493#comment-17236493
]
ASF GitHub Bot commented on GEODE-8521:
---
dschneider-pivotal commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r528011618
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringImpl.java
##
@@ -96,39 +98,60 @@ public void updateThreadStatus() {
@Override
public boolean startMonitor(Mode mode) {
-AbstractExecutor absExtgroup;
+return startMonitoring(createAbstractExecutor(mode));
+ }
+
+ @Override
+ public void endMonitor() {
+this.monitorMap.remove(Thread.currentThread().getId());
+ }
+
+ @VisibleForTesting
+ boolean isMonitoring() {
+return monitorMap.containsKey(Thread.currentThread().getId());
+ }
+
+ @Override
+ public AbstractExecutor createAbstractExecutor(Mode mode) {
switch (mode) {
case FunctionExecutor:
-absExtgroup = new FunctionExecutionPooledExecutorGroup(this);
-break;
+return new FunctionExecutionPooledExecutorGroup();
case PooledExecutor:
-absExtgroup = new PooledExecutorGroup(this);
-break;
+return new PooledExecutorGroup();
case SerialQueuedExecutor:
-absExtgroup = new SerialQueuedExecutorGroup(this);
-break;
+return new SerialQueuedExecutorGroup();
case OneTaskOnlyExecutor:
-absExtgroup = new OneTaskOnlyExecutorGroup(this);
-break;
+return new OneTaskOnlyExecutorGroup();
case ScheduledThreadExecutor:
-absExtgroup = new ScheduledThreadPoolExecutorWKAGroup(this);
-break;
+return new ScheduledThreadPoolExecutorWKAGroup();
case AGSExecutor:
-absExtgroup = new GatewaySenderEventProcessorGroup(this);
-break;
+return new GatewaySenderEventProcessorGroup();
+ case P2PReaderExecutor:
+return new P2PReaderExecutorGroup();
default:
-return false;
+throw new IllegalStateException("Unhandled mode=" + mode);
}
-this.monitorMap.put(Thread.currentThread().getId(), absExtgroup);
+ }
+
+ @Override
+ public boolean startMonitoring(AbstractExecutor executor) {
+executor.setStartTime(System.currentTimeMillis());
Review comment:
the p2p reader now simply sets a volatile boolean before and after
messageDispatch.
the startTime for a p2p reader will now be set by the monitor thread.
Let me know what you think
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add P2P message reader threads to thread monitoring
> ---
>
> Key: GEODE-8521
> URL: https://issues.apache.org/jira/browse/GEODE-8521
> Project: Geode
> Issue Type: Wish
> Components: messaging
>Reporter: Kirk Lund
>Assignee: Darrel Schneider
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Add P2P message reader threads to thread monitoring to help with identifying
> stuck P2P message readers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8739) Split brain when locators exhaust join attempts on non existant servers
[ https://issues.apache.org/jira/browse/GEODE-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236503#comment-17236503 ] Bruce J Schuchardt commented on GEODE-8739: --- I don't know how you're shutting down the cluster, but if you're using shutdown-all maybe we could change the handling of that in the locators to have them delete the .dat files. > Split brain when locators exhaust join attempts on non existant servers > --- > > Key: GEODE-8739 > URL: https://issues.apache.org/jira/browse/GEODE-8739 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Jason Huynh >Priority: Major > Attachments: exportedLogs_locator-0.zip, exportedLogs_locator-1.zip > > > The hypothesis: "if there is a locator view .dat file with several > non-existent servers then then locators will waste all of their join attempts > on the servers instead of finding each other" > Scenario is a test/user attempts to recreate a cluster with existing .dat and > persistent files. The locators are spun in parallel and from the analysis, > it looks like they are able to communicate with each other, but then end up > forming their own ds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236539#comment-17236539
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r528036088
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -0,0 +1,101 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
contributor license
+ * agreements. See the NOTICE file distributed with this work for additional
information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express
+ * or implied. See the License for the specific language governing permissions
and limitations under
+ * the License.
+ */
+package org.apache.geode.internal;
+
+import static java.util.concurrent.TimeUnit.NANOSECONDS;
+
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+import java.util.function.Predicate;
+import java.util.function.Supplier;
+
+import org.apache.geode.annotations.VisibleForTesting;
+
+/**
+ * Utility class for retrying operations.
+ */
+public class Retry {
+
+ interface Timer {
+long nanoTime();
+
+void sleep(long sleepTimeInNano) throws InterruptedException;
+ }
+
+ static class SteadyTimer implements Timer {
+@Override
+public long nanoTime() {
+ return System.nanoTime();
+}
+
+@Override
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ long millis = NANOSECONDS.toMillis(sleepTimeInNano);
+ // avoid throwing IllegalArgumentException
+ if (millis > 0) {
+Thread.sleep(millis);
+ }
+}
+ }
+
+ private static final SteadyTimer steadyClock = new SteadyTimer();
+
+ /**
+ * Try the supplier function until the predicate is true or timeout occurs.
+ *
+ * @param timeout to retry for
+ * @param timeoutUnit the unit for timeout
+ * @param interval time between each try
+ * @param intervalUnit the unit for interval
+ * @param supplier to execute until predicate is true or times out
+ * @param predicate to test for retry
+ * @param type of return value
+ * @return value from supplier after it passes predicate or times out.
+ */
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate) throws TimeoutException, InterruptedException {
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
+ }
+
+ @VisibleForTesting
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
+ Supplier supplier,
+ Predicate predicate,
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
+long intervalNano = NANOSECONDS.convert(interval, intervalUnit);
+
+T value;
+for (;;) {
+ value = supplier.get();
+ if (predicate.test(value)) {
+return value;
+ } else {
+// if there is still more time left after we sleep for interval
period, then sleep and retry
+// otherwise break out and throw TimeoutException
+if ((timer.nanoTime() + intervalNano) < until) {
Review comment:
@Bill per our offline meetings, can I merge this now?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Timing between DNS and Geode startup can result in permanent unknown host
> exceptions.
> -
>
> Key: GEODE-8623
> URL: https://issues.apache.org/jira/browse/GEODE-8623
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0, 1.9.1, 1.10.0, 1.9.2, 1.11.0, 1.12.0, 1.13.0,
> 1.14.0, 1.13.1
>Reporter: Jacob Barrett
>Priority: Minor
> Labels: pull-request-available
>
> In a managed environment were local host name DNS entries and the startup of
> Geode happen concurrently it is possible for Geode to fail name resolution in
> the local ho
[jira] [Commented] (GEODE-8667) Duplicate online Oplog compaction after offline Oplog compaction
[ https://issues.apache.org/jira/browse/GEODE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236540#comment-17236540 ] ASF GitHub Bot commented on GEODE-8667: --- jchen21 commented on pull request #5689: URL: https://github.com/apache/geode/pull/5689#issuecomment-731472883 When compacting oplogs offline, it creates a new krf and persists `totalCount` with `0` in Oplog constructor. Then live entries are copied from old oplogs to the new oplog. `totalCount` of the new oplog is updated during this process. However, the updated `totalCount` is not persisted. Its persisted value is still `0`, although the oplog is non-empty after compaction. During recovery, the value of `totalCount` is recovered from krf as `0`. `totalLiveCount` is incremented as the oplog is recovered. `totalCount` remains `0`. Therefore, if `totalCount` == 0 and `totalLiveCount` > 0, no compaction is needed. Since this condition shows that offline compaction is just done before recovery. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Duplicate online Oplog compaction after offline Oplog compaction > > > Key: GEODE-8667 > URL: https://issues.apache.org/jira/browse/GEODE-8667 > Project: Geode > Issue Type: Bug >Reporter: Jianxia Chen >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Use `compact offline-disk-store` command to compact the Oplogs offline. > Then restart the servers. > The logs show OplogCompactor thread is compacting Oplogs again when > restarting the servers, even though the Oplogs were just compacted offline. > For example: > ``` > [info 2020/10/27 16:32:22.534 PDT tid=0x35] Recovered > values for disk store DEFAULT with unique id > 76393d3c-dd10-4b89-b655-821d37631774 > [info 2020/10/27 16:32:22.535 PDT > tid=0x35] OplogCompactor for DEFAULT compaction oplog id(s): oplog#2 > [info 2020/10/27 16:32:22.537 PDT > tid=0x35] compaction did 2 creates and updates in 2 ms > [info 2020/10/27 16:32:22.537 PDT tid=0x36] Deleted > oplog#2 crf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 krf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 drf for disk store DEFAULT. > ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8411) CI Failure: Jetty9CachingClientServerTest. containersShouldShareDataRemovals() fails with comparison failure
[
https://issues.apache.org/jira/browse/GEODE-8411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236541#comment-17236541
]
Geode Integration commented on GEODE-8411:
--
Seen on support/1.12 in [DistributedTestOpenJDK8
#100|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK8/builds/100]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0121/test-results/distributedTest/1604430325/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0121/test-artifacts/1604430325/distributedtestfiles-OpenJDK8-1.12.1-build.0121.tgz].
> CI Failure: Jetty9CachingClientServerTest.
> containersShouldShareDataRemovals() fails with comparison failure
>
>
> Key: GEODE-8411
> URL: https://issues.apache.org/jira/browse/GEODE-8411
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> We saw Jetty9CachingClientServerTest fail with a Comparison failure in a CI
> run.
> {code:java}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> containersShouldShareDataRemovals FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[Foo]">
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7761) DistributedAckRegionCCEOffHeapDUnitTest > testClearOnNonReplicateWithConcurrentEvents
[
https://issues.apache.org/jira/browse/GEODE-7761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236542#comment-17236542
]
Geode Integration commented on GEODE-7761:
--
Seen on support/1.12 in [DistributedTestOpenJDK11
#102|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/DistributedTestOpenJDK11/builds/102]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0124/test-results/distributedTest/1604631024/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0124/test-artifacts/1604631024/distributedtestfiles-OpenJDK11-1.12.1-build.0124.tgz].
> DistributedAckRegionCCEOffHeapDUnitTest >
> testClearOnNonReplicateWithConcurrentEvents
> -
>
> Key: GEODE-7761
> URL: https://issues.apache.org/jira/browse/GEODE-7761
> Project: Geode
> Issue Type: Bug
> Components: offheap, regions
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> CI Failure in DistributedTestOpenJDK11
> {noformat}
> org.apache.geode.cache30.DistributedAckRegionCCEOffHeapDUnitTest >
> testClearOnNonReplicateWithConcurrentEvents FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.cache30.MultiVMRegionTestCase expected:<[3]> but was:<[0]>
> within 300 seconds.
> Caused by:
> org.junit.ComparisonFailure: expected:<[3]> but was:<[0]>
> {noformat}
> Logs:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0237/test-results/distributedTest/1580506766/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0237/test-artifacts/1580506766/distributedtestfiles-OpenJDK11-1.12.0-SNAPSHOT.0237.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-5782) LauncherMemberMXBeanIntegrationTest can fail intermittently
[
https://issues.apache.org/jira/browse/GEODE-5782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236567#comment-17236567
]
Geode Integration commented on GEODE-5782:
--
Seen in [WindowsCoreIntegrationTestOpenJDK11
#587|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/587]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0504/test-results/integrationTest/1605924953/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0504/test-artifacts/1605924953/windows-coreintegrationtestfiles-OpenJDK11-1.14.0-build.0504.tgz].
> LauncherMemberMXBeanIntegrationTest can fail intermittently
> ---
>
> Key: GEODE-5782
> URL: https://issues.apache.org/jira/browse/GEODE-5782
> Project: Geode
> Issue Type: Test
> Components: jmx
>Affects Versions: 1.9.0
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Noticed this failure:
> {noformat}
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest >
> showOSMetrics_reconstructsOSMetricsFromCompositeDataType FAILED
> org.junit.ComparisonFailure: expected:<204.[68]> but was:<204.[55]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.distributed.LauncherMemberMXBeanIntegrationTest.showOSMetrics_reconstructsOSMetricsFromCompositeDataType(LauncherMemberMXBeanIntegrationTest.java:143)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8737) Create new geode example about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17236585#comment-17236585 ] ASF GitHub Bot commented on GEODE-8737: --- yrashish commented on pull request #104: URL: https://github.com/apache/geode-examples/pull/104#issuecomment-731508759 @davebarnes97 Thanks for the feedback. I will do the required changes. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Create new geode example about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > Labels: pull-request-available > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
