[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241317#comment-17241317
]
ASF GitHub Bot commented on GEODE-8742:
---
mkevo commented on pull request #5777:
URL: https://github.com/apache/geode/pull/5777#issuecomment-736281496
> It's possible that these changes may overlap/conflict with #5770. It could
be a good idea to rebase off that branch and confirm that the issue these
changes are intended to fix is still present with the above PR in place.
Hi @DonalEvans ,
I tried with this PR and the issue still exist.
With this change issue dissapear.
There is some test failing, I'm trying to fix it.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8746. - Resolution: Cannot Reproduce as of Nov 30 bionic image https://www.googleapis.com/compute/v1/projects/ubuntu-os-cloud/global/images/ubuntu-minimal-1804-bionic-v20201130 the issue is no longer reproducible > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8748) Altering expiry time on proxy region causes NPE
[ https://issues.apache.org/jira/browse/GEODE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241221#comment-17241221 ] ASF GitHub Bot commented on GEODE-8748: --- nabarunnag opened a new pull request #5790: URL: https://github.com/apache/geode/pull/5790 * When a region is created with zero local memory, there is no bucket regions created. * When alter region is called on this proxy region to alter expiry, it tries to manipulate the bucket region. * But there are no buckets and hence NPE is thrown. * In this commit a null check is done before alter the bucket regions. * Configs still need to changed to prevent restart issues. * This similar to the check done in setEntryTimeToLive in PartitionedRegion class 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 > Altering expiry time on proxy region causes NPE > --- > > Key: GEODE-8748 > URL: https://issues.apache.org/jira/browse/GEODE-8748 > Project: Geode > Issue Type: Task > Components: expiration >Reporter: Nabarun Nag >Priority: Major > > When we execute > "create region --name=region --type=PARTITION_PROXY --group=proxy" > "alter region --name=region --entry-time-to-live-expiration=1000 > --entry-time-to-live-expiration-action=destroy --group=proxy" > > This results in an NPE. Also if there is a mixture of proxy and non-proxy > versions of the same region and we could alter some of the non-proxy but the > proxy region failed on alter commands, then restarts will start encountering > problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8748) Altering expiry time on proxy region causes NPE
[ https://issues.apache.org/jira/browse/GEODE-8748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8748: -- Labels: pull-request-available (was: ) > Altering expiry time on proxy region causes NPE > --- > > Key: GEODE-8748 > URL: https://issues.apache.org/jira/browse/GEODE-8748 > Project: Geode > Issue Type: Task > Components: expiration >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > When we execute > "create region --name=region --type=PARTITION_PROXY --group=proxy" > "alter region --name=region --entry-time-to-live-expiration=1000 > --entry-time-to-live-expiration-action=destroy --group=proxy" > > This results in an NPE. Also if there is a mixture of proxy and non-proxy > versions of the same region and we could alter some of the non-proxy but the > proxy region failed on alter commands, then restarts will start encountering > problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8748) Altering expiry time on proxy region causes NPE
Nabarun Nag created GEODE-8748: -- Summary: Altering expiry time on proxy region causes NPE Key: GEODE-8748 URL: https://issues.apache.org/jira/browse/GEODE-8748 Project: Geode Issue Type: Task Components: expiration Reporter: Nabarun Nag When we execute "create region --name=region --type=PARTITION_PROXY --group=proxy" "alter region --name=region --entry-time-to-live-expiration=1000 --entry-time-to-live-expiration-action=destroy --group=proxy" This results in an NPE. Also if there is a mixture of proxy and non-proxy versions of the same region and we could alter some of the non-proxy but the proxy region failed on alter commands, then restarts will start encountering problems. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8740. - Fix Version/s: 1.14.0 Resolution: Fixed > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8736) maintain native and docs Geode version as part of release scripts
[ https://issues.apache.org/jira/browse/GEODE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-8736. - Fix Version/s: 1.14.0 Resolution: Fixed > maintain native and docs Geode version as part of release scripts > - > > Key: GEODE-8736 > URL: https://issues.apache.org/jira/browse/GEODE-8736 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > travis, lgtm, and Dockerfile in native (support branch and develop) should be > auto-updated when a new version of Geode is released > product_version for Geode docs should be auto-updated when a new version of > Geode is released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[
https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241180#comment-17241180
]
ASF GitHub Bot commented on GEODE-8745:
---
nabarunnag commented on a change in pull request #5770:
URL: https://github.com/apache/geode/pull/5770#discussion_r533013553
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANPersistenceEnabledGatewaySenderDUnitTest.java
##
@@ -603,27 +605,32 @@ public void
testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueue
vm7.invoke(() ->
WANTestBase.createPersistentReplicatedRegion(getTestMethodName() + "_RR", "ln",
isOffHeap()));
+vm4.invoke(() -> WANTestBase.pauseSender("ln"));
+vm5.invoke(() -> WANTestBase.pauseSender("ln"));
+
vm4.invoke(() -> WANTestBase.doPuts(getTestMethodName() + "_RR", 1000));
logger.info("Completed puts in the region");
vm4.invoke(() -> WANTestBase.stopSender("ln"));
vm5.invoke(() -> WANTestBase.stopSender("ln"));
-logger.info("Stopped all the senders. ");
-// Create receiver on remote site
-createReceiverInVMs(vm2, vm3);
+logger.info("Stopped all the senders. ");
Review comment:
A valid point Donal. I am creating another GEODE ticket to just remove
all the logger.info in tests. There are a couple of more statements that went
in other commits.
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
> Closing the region backing the queue when the serial gateway sender is
> stopped.
> ---
>
> Key: GEODE-8745
> URL: https://issues.apache.org/jira/browse/GEODE-8745
> Project: Geode
> Issue Type: Task
> Components: wan
>Reporter: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> In the commit for GEODE-7458, when the sender is stopped, the region backing
> the queues are no more closed, but just remove the cache listeners.
> This is causing a problem, as the regions continue to exist, it keeps on
> storing entry events and hence the queue size never gets to zero.
> Also, as the region exists but before attaching the cache listener when
> restarting the sender leads to entries being never removed from the
> unprocessed event map.
>
> As mention in the PR for GEODE-7458 - "This option is only applicable for
> Gateway Senders with enabled persistence."
> Hence believe that it is ok to close the region as the disk files will still
> be maintained. so when we restart the values can be obtained back from the
> disk stores.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241166#comment-17241166 ] ASF subversion and git services commented on GEODE-8740: Commit 4a3ac924b6a392ca87f78fa6ee774e348293dc61 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a3ac92 ] GEODE-8740: increase test job timeouts (#5771) > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241165#comment-17241165 ] ASF GitHub Bot commented on GEODE-8740: --- onichols-pivotal merged pull request #5771: URL: https://github.com/apache/geode/pull/5771 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 > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8744) multiple versions of json-smart
[ https://issues.apache.org/jira/browse/GEODE-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241164#comment-17241164 ] ASF subversion and git services commented on GEODE-8744: Commit a53be62e1390d6032d2e077829a904d29fa42040 in geode's branch refs/heads/support/1.13 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a53be62 ] GEODE-8744: fix multiple versions of json-smart (#5776) > multiple versions of json-smart > --- > > Key: GEODE-8744 > URL: https://issues.apache.org/jira/browse/GEODE-8744 > Project: Geode > Issue Type: Improvement > Components: release >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > develop and 1.12 release binaries contain only json-smart 2.3, but 1.13.1 > contained both 1.3.1 and 2.3 due to the particular version of > spring-security-oauth2-client in this release. 2.3 is preferred and should > be used in all places -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8744) multiple versions of json-smart
[ https://issues.apache.org/jira/browse/GEODE-8744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241163#comment-17241163 ] ASF GitHub Bot commented on GEODE-8744: --- onichols-pivotal merged pull request #5776: URL: https://github.com/apache/geode/pull/5776 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 > multiple versions of json-smart > --- > > Key: GEODE-8744 > URL: https://issues.apache.org/jira/browse/GEODE-8744 > Project: Geode > Issue Type: Improvement > Components: release >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > develop and 1.12 release binaries contain only json-smart 2.3, but 1.13.1 > contained both 1.3.1 and 2.3 due to the particular version of > spring-security-oauth2-client in this release. 2.3 is preferred and should > be used in all places -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8736) maintain native and docs Geode version as part of release scripts
[ https://issues.apache.org/jira/browse/GEODE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241162#comment-17241162 ] ASF subversion and git services commented on GEODE-8736: Commit cff59edf12f993d1cb907856f514209bc82fc583 in geode's branch refs/heads/develop from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cff59ed ] GEODE-8736: maintain geode version for native and docs (#5765) * maintain 3-digit product version for docs * update travis, lgtm, and Dockerfile on native develop as well as support branch * update branch for cache-dependencies scripts * keep rc pipeline green if geode-examples triggers it post-release > maintain native and docs Geode version as part of release scripts > - > > Key: GEODE-8736 > URL: https://issues.apache.org/jira/browse/GEODE-8736 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > travis, lgtm, and Dockerfile in native (support branch and develop) should be > auto-updated when a new version of Geode is released > product_version for Geode docs should be auto-updated when a new version of > Geode is released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8736) maintain native and docs Geode version as part of release scripts
[ https://issues.apache.org/jira/browse/GEODE-8736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241161#comment-17241161 ] ASF GitHub Bot commented on GEODE-8736: --- onichols-pivotal merged pull request #5765: URL: https://github.com/apache/geode/pull/5765 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 > maintain native and docs Geode version as part of release scripts > - > > Key: GEODE-8736 > URL: https://issues.apache.org/jira/browse/GEODE-8736 > Project: Geode > Issue Type: Improvement > Components: release >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > travis, lgtm, and Dockerfile in native (support branch and develop) should be > auto-updated when a new version of Geode is released > product_version for Geode docs should be auto-updated when a new version of > Geode is released. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241157#comment-17241157 ] ASF GitHub Bot commented on GEODE-8746: --- onichols-pivotal closed pull request #5784: URL: https://github.com/apache/geode/pull/5784 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 > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241156#comment-17241156 ] ASF GitHub Bot commented on GEODE-8746: --- onichols-pivotal closed pull request #5779: URL: https://github.com/apache/geode/pull/5779 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 > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- 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=17241152#comment-17241152 ] ASF GitHub Bot commented on GEODE-8738: --- alb3rtobr commented on a change in pull request #5766: URL: https://github.com/apache/geode/pull/5766#discussion_r532989605 ## File path: geode-docs/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html.md.erb ## @@ -387,3 +387,51 @@ boglesbymac(ny-3:88715):36808 | 5371 | 5 |["boglesbymac(ln-1:8865 boglesbymac(ny-4:88724):52993 | 5247 | 6 |["boglesbymac(ln-1:88651):48277","boglesbymac(ln-4:88681):42784","boglesbymac(ln-2:88662):12796","boglesbymac(ln-3:88672):43675"] ``` +### Configuring just one IP address and port to access all gateway receivers in a site + +There could be WAN deployments in which we do not want to expose the IP address and port of every gateway receiver to the other site but instead expose just one IP address and port for all gateway receivers. This way, the internal topology of the site is hidden to the other site. This case is quite common in cloud deployments, in which a reverse proxy/load balancer distributes incoming requests to the site (in our case, replication requests) among the available servers (in our case, gateway receivers). + +<%=vars.product_name%> supports this configuration by means of a particular use of the hostname-for-senders, start-port and end-port parameters of the gateway receiver. + +In order to configure a WAN deployment that hides the gateway receivers behind the same IP address and port, all the gateway receivers must have the same value for the hostname-for-senders parameter (the hostname or IP address to be used by clients to access them) and the same value in the start-port and end-port parameters (the port to be used by clients to access them). + +As an example, a deployment in which all gateway receivers of a site are accessed via the "gateway1.mycompany.com" hostname and port "1971", every gateway receiver in that site must be configured as follows: + +``` pre +gfsh> create gateway-receiver --hostname-for-senders="gateway1.mycompany.com" --start-port=1971 --end-port=1971 +``` + +The following output shows how the receiver side would look like after this configuration if 4 gateway recievers were configured: Review comment: There is a typo: "recievers" 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] [Assigned] (GEODE-8543) Client disconnects from server due to exception on other server
[ https://issues.apache.org/jira/browse/GEODE-8543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-8543: --- Assignee: (was: Alberto Bustamante Reyes) > Client disconnects from server due to exception on other server > --- > > Key: GEODE-8543 > URL: https://issues.apache.org/jira/browse/GEODE-8543 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Alberto Bustamante Reyes >Priority: Major > > In ThinClientBaseDM::handleEPError when the client receives an exception from > a given endpoint, it will mark that server dead if in the exception contains > "java.lang.OutOfMemoryError", > "org.apache.geode.distributed.ShutdownException" or > "org.apache.geode.cache.CacheClosedException" ( in > ThinClientBaseDM::unrecoverableServerError() ) > The problem is that the server causing the exception can be a different > server than the endpoint the client is connected to. In that case, > the client will wrongly close a connection to a working server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8419:
Fix Version/s: 1.12.1
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
[
https://issues.apache.org/jira/browse/GEODE-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241134#comment-17241134
]
Bill Burcham commented on GEODE-8730:
-
Looking at the {{AvailablePort}} and {{MembershipConfig}} classes I see that
Geode should only pick random ports in these ranges by default:
20001-2
41000-61000
So how/why did something apparently pick port 40405 before the second cache
server was able to bind to it?
We see the first cache server says it's bound to 40404. Has something changed
in {{AvailablePort}}?
> CI failure: DualServerSNIAcceptanceTest fails to start server because port is
> in use
>
>
> Key: GEODE-8730
> URL: https://issues.apache.org/jira/browse/GEODE-8730
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Bill Burcham
>Priority: Major
>
> The run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
> {noformat}
> org.apache.geode.client.sni.DualServerSNIAcceptanceTest > classMethod FAILED
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter-2.gfsh' returned exit code 1
> The output was:
> 1. Executing - start locator --name=locator-maeve --connect=false
> --redirect-output --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> ...
> Locator in /locator-maeve on geode[10334] as locator-maeve is currently
> online.
> Process ID: 47
> Uptime: 16 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /locator-maeve/locator-maeve.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.DISABLE_REDIRECTION_CONFIGURATION=true
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 2. Executing - start server --name=server-dolores --group=group-dolores
> --hostname-for-clients=server-dolores --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> ...
> Server in /server-dolores on geode[40404] as server-dolores is currently
> online.
> Process ID: 199
> Uptime: 5 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /server-dolores/server-dolores.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=geode[10334]
> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=group-dolores
> -Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 3. Executing - start server --name=server-clementine
> --group=group-clementine --hostname-for-clients=server-clementine
> --server-port=40405 --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-clementine-keystore.jks
> ..The Cache Server process terminated unexpectedly with exit status
> 1. Please refer to the log file in /server-clementine for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error
> occurred while starting a Server in /server-clementine on geode[40405]:
> Network is unreachable; port (40405) is not available on localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:852)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: java.net.BindException: Network is unreachable; port (40405)
> is not available on localhost.
> at
>
[jira] [Commented] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241128#comment-17241128 ] ASF GitHub Bot commented on GEODE-8746: --- onichols-pivotal opened a new pull request #5784: URL: https://github.com/apache/geode/pull/5784 wip do not review do not merge this is an experiment to run older develop code (before we started bumping dependencies) on the latest ubuntu image to confirm that dependency bumps on develop is why it's not seeing problems but 1.13 is 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 > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
[
https://issues.apache.org/jira/browse/GEODE-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8730:
Comment: was deleted
(was: This is odd because the error message indicates that port 40404 was
unavailable inside the Docker container. It would be one thing if it was
unavailable on the host (which could indicate some other test processes were
lingering on the host.) But this indicates something in the container seems to
be using port 40404.)
> CI failure: DualServerSNIAcceptanceTest fails to start server because port is
> in use
>
>
> Key: GEODE-8730
> URL: https://issues.apache.org/jira/browse/GEODE-8730
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Bill Burcham
>Priority: Major
>
> The run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
> {noformat}
> org.apache.geode.client.sni.DualServerSNIAcceptanceTest > classMethod FAILED
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter-2.gfsh' returned exit code 1
> The output was:
> 1. Executing - start locator --name=locator-maeve --connect=false
> --redirect-output --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> ...
> Locator in /locator-maeve on geode[10334] as locator-maeve is currently
> online.
> Process ID: 47
> Uptime: 16 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /locator-maeve/locator-maeve.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.DISABLE_REDIRECTION_CONFIGURATION=true
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 2. Executing - start server --name=server-dolores --group=group-dolores
> --hostname-for-clients=server-dolores --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> ...
> Server in /server-dolores on geode[40404] as server-dolores is currently
> online.
> Process ID: 199
> Uptime: 5 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /server-dolores/server-dolores.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=geode[10334]
> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=group-dolores
> -Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 3. Executing - start server --name=server-clementine
> --group=group-clementine --hostname-for-clients=server-clementine
> --server-port=40405 --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-clementine-keystore.jks
> ..The Cache Server process terminated unexpectedly with exit status
> 1. Please refer to the log file in /server-clementine for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error
> occurred while starting a Server in /server-clementine on geode[40405]:
> Network is unreachable; port (40405) is not available on localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:852)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: java.net.BindException: Network is unreachable; port (40405)
> is not available on localhost.
> at
>
[jira] [Commented] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
[
https://issues.apache.org/jira/browse/GEODE-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241126#comment-17241126
]
Bill Burcham commented on GEODE-8730:
-
Hmm we can see that in step (2) server "dolores" picked port 40404 ahead of
server "clementine"'s attempt at step (3). Here's some output from step (2):
{code:java}
Server in /server-dolores on geode[40404] as server-dolores is currently
online.
{code}
> CI failure: DualServerSNIAcceptanceTest fails to start server because port is
> in use
>
>
> Key: GEODE-8730
> URL: https://issues.apache.org/jira/browse/GEODE-8730
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Bill Burcham
>Priority: Major
>
> The run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
> {noformat}
> org.apache.geode.client.sni.DualServerSNIAcceptanceTest > classMethod FAILED
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter-2.gfsh' returned exit code 1
> The output was:
> 1. Executing - start locator --name=locator-maeve --connect=false
> --redirect-output --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> ...
> Locator in /locator-maeve on geode[10334] as locator-maeve is currently
> online.
> Process ID: 47
> Uptime: 16 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /locator-maeve/locator-maeve.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.DISABLE_REDIRECTION_CONFIGURATION=true
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 2. Executing - start server --name=server-dolores --group=group-dolores
> --hostname-for-clients=server-dolores --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> ...
> Server in /server-dolores on geode[40404] as server-dolores is currently
> online.
> Process ID: 199
> Uptime: 5 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /server-dolores/server-dolores.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=geode[10334]
> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=group-dolores
> -Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 3. Executing - start server --name=server-clementine
> --group=group-clementine --hostname-for-clients=server-clementine
> --server-port=40405 --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-clementine-keystore.jks
> ..The Cache Server process terminated unexpectedly with exit status
> 1. Please refer to the log file in /server-clementine for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error
> occurred while starting a Server in /server-clementine on geode[40405]:
> Network is unreachable; port (40405) is not available on localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:852)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: java.net.BindException: Network is unreachable; port (40405)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
>
[jira] [Issue Comment Deleted] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
[
https://issues.apache.org/jira/browse/GEODE-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-8730:
Comment: was deleted
(was: Hmm we can see that in step (2) server "dolores" picked port 40404 ahead
of server "clementine"'s attempt at step (3). Here's some output from step (2):
{code:java}
Server in /server-dolores on geode[40404] as server-dolores is currently
online.
{code}
)
> CI failure: DualServerSNIAcceptanceTest fails to start server because port is
> in use
>
>
> Key: GEODE-8730
> URL: https://issues.apache.org/jira/browse/GEODE-8730
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Bill Burcham
>Priority: Major
>
> The run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
> {noformat}
> org.apache.geode.client.sni.DualServerSNIAcceptanceTest > classMethod FAILED
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter-2.gfsh' returned exit code 1
> The output was:
> 1. Executing - start locator --name=locator-maeve --connect=false
> --redirect-output --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> ...
> Locator in /locator-maeve on geode[10334] as locator-maeve is currently
> online.
> Process ID: 47
> Uptime: 16 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /locator-maeve/locator-maeve.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.DISABLE_REDIRECTION_CONFIGURATION=true
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 2. Executing - start server --name=server-dolores --group=group-dolores
> --hostname-for-clients=server-dolores --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> ...
> Server in /server-dolores on geode[40404] as server-dolores is currently
> online.
> Process ID: 199
> Uptime: 5 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /server-dolores/server-dolores.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=geode[10334]
> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=group-dolores
> -Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 3. Executing - start server --name=server-clementine
> --group=group-clementine --hostname-for-clients=server-clementine
> --server-port=40405 --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-clementine-keystore.jks
> ..The Cache Server process terminated unexpectedly with exit status
> 1. Please refer to the log file in /server-clementine for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error
> occurred while starting a Server in /server-clementine on geode[40405]:
> Network is unreachable; port (40405) is not available on localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:852)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: java.net.BindException: Network is unreachable; port (40405)
> is not available on localhost.
> at
> org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)
> at
>
[jira] [Commented] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
[
https://issues.apache.org/jira/browse/GEODE-8730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241124#comment-17241124
]
Bill Burcham commented on GEODE-8730:
-
This is odd because the error message indicates that port 40404 was unavailable
inside the Docker container. It would be one thing if it was unavailable on the
host (which could indicate some other test processes were lingering on the
host.) But this indicates something in the container seems to be using port
40404.
> CI failure: DualServerSNIAcceptanceTest fails to start server because port is
> in use
>
>
> Key: GEODE-8730
> URL: https://issues.apache.org/jira/browse/GEODE-8730
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Darrel Schneider
>Assignee: Bill Burcham
>Priority: Major
>
> The run is here:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
> {noformat}
> org.apache.geode.client.sni.DualServerSNIAcceptanceTest > classMethod FAILED
> com.palantir.docker.compose.execution.DockerExecutionException:
> 'docker-compose exec -T geode gfsh run
> --file=/geode/scripts/geode-starter-2.gfsh' returned exit code 1
> The output was:
> 1. Executing - start locator --name=locator-maeve --connect=false
> --redirect-output --hostname-for-clients=locator-maeve
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> ...
> Locator in /locator-maeve on geode[10334] as locator-maeve is currently
> online.
> Process ID: 47
> Uptime: 16 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /locator-maeve/locator-maeve.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> -Dgemfire.OSProcess.DISABLE_REDIRECTION_CONFIGURATION=true
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 2. Executing - start server --name=server-dolores --group=group-dolores
> --hostname-for-clients=server-dolores --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> ...
> Server in /server-dolores on geode[40404] as server-dolores is currently
> online.
> Process ID: 199
> Uptime: 5 seconds
> Geode Version: 1.14.0-build.0
> Java Version: 11.0.9.1
> Log File: /server-dolores/server-dolores.log
> JVM Arguments: -DgemfirePropertyFile=/geode/config/gemfire.properties
> -DgemfireSecurityPropertyFile=/geode/config/gfsecurity.properties
> -Dgemfire.start-dev-rest-api=false -Dgemfire.locators=geode[10334]
> -Dgemfire.use-cluster-configuration=true -Dgemfire.groups=group-dolores
> -Dgemfire.ssl-keystore=/geode/config/server-dolores-keystore.jks
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> Class-Path:
> /geode/lib/geode-core-1.14.0-build.0.jar:/geode/lib/geode-dependencies.jar
> 3. Executing - start server --name=server-clementine
> --group=group-clementine --hostname-for-clients=server-clementine
> --server-port=40405 --locators=geode[10334]
> --properties-file=/geode/config/gemfire.properties
> --security-properties-file=
> --J=-Dgemfire.ssl-keystore=/geode/config/server-clementine-keystore.jks
> ..The Cache Server process terminated unexpectedly with exit status
> 1. Please refer to the log file in /server-clementine for full details.
> Exception in thread "main" java.lang.RuntimeException: An IO error
> occurred while starting a Server in /server-clementine on geode[40405]:
> Network is unreachable; port (40405) is not available on localhost.
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:852)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:737)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:256)
> Caused by: java.net.BindException: Network is unreachable; port (40405)
> is not available on localhost.
> at
>
[GitHub] [geode-kafka-connector] nabarunnag closed issue #3: Correct Kafka spelling
nabarunnag closed issue #3: URL: https://github.com/apache/geode-kafka-connector/issues/3 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
[jira] [Assigned] (GEODE-8747) Collect library dependencies into single dependency
[
https://issues.apache.org/jira/browse/GEODE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-8747:
Assignee: Udo Kohlmeyer
> Collect library dependencies into single dependency
> ---
>
> Key: GEODE-8747
> URL: https://issues.apache.org/jira/browse/GEODE-8747
> Project: Geode
> Issue Type: New Feature
> Components: build
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
>
> Library dependencies like Spring, Jackson, Spring Security, etc. usually have
> many dependencies. Which if used within a module, require the listing each of
> these dependencies.
> With the addition of ClassLoader Isolation a need arose, where these
> libraries where loaded into a single ClassLoader, instead of being loaded by
> the ClassLoaders of each of the modules that depended on these libraries.
> This feature is to replace the following:
> {code:groovy}
> implementation('org.springframework:spring-core')
> implementation('org.springframework:spring-beans')
> implementation('org.springframework:spring-context')
> implementation('org.springframework:spring-jcl')
> implementation('org.springframework:spring-web')
> implementation('org.springframework.shell:spring-shell')
> {code}
> with a single entry:
> {code:groovy}
>implementation(project(':frameworks:springframework'))
> {code}
> What this new construct allows for is a pattern closer to "using a framework"
> without having to explicitly define all the library dependencies. In this
> approach, we "use" a framework library, rather than knowing all of the
> internal dependencies.
> With this change, the ClassLoader isolation work, will only load each
> dependency once.
> Currently identified dependencies that require to be loaded only once are:
> Spring and Jackson
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8747) Collect library dependencies into single dependency
[
https://issues.apache.org/jira/browse/GEODE-8747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-8747:
Assignee: Patrick Johnson (was: Udo Kohlmeyer)
> Collect library dependencies into single dependency
> ---
>
> Key: GEODE-8747
> URL: https://issues.apache.org/jira/browse/GEODE-8747
> Project: Geode
> Issue Type: New Feature
> Components: build
>Reporter: Udo Kohlmeyer
>Assignee: Patrick Johnson
>Priority: Major
>
> Library dependencies like Spring, Jackson, Spring Security, etc. usually have
> many dependencies. Which if used within a module, require the listing each of
> these dependencies.
> With the addition of ClassLoader Isolation a need arose, where these
> libraries where loaded into a single ClassLoader, instead of being loaded by
> the ClassLoaders of each of the modules that depended on these libraries.
> This feature is to replace the following:
> {code:groovy}
> implementation('org.springframework:spring-core')
> implementation('org.springframework:spring-beans')
> implementation('org.springframework:spring-context')
> implementation('org.springframework:spring-jcl')
> implementation('org.springframework:spring-web')
> implementation('org.springframework.shell:spring-shell')
> {code}
> with a single entry:
> {code:groovy}
>implementation(project(':frameworks:springframework'))
> {code}
> What this new construct allows for is a pattern closer to "using a framework"
> without having to explicitly define all the library dependencies. In this
> approach, we "use" a framework library, rather than knowing all of the
> internal dependencies.
> With this change, the ClassLoader isolation work, will only load each
> dependency once.
> Currently identified dependencies that require to be loaded only once are:
> Spring and Jackson
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241121#comment-17241121
]
ASF subversion and git services commented on GEODE-8419:
Commit a6f3ea2f47b5d22410c96293794f62440b79edf4 in geode's branch
refs/heads/support/1.12 from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6f3ea2 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
Configure cipher suites when creating an SSLEngine
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241120#comment-17241120
]
ASF GitHub Bot commented on GEODE-8419:
---
Bill merged pull request #5587:
URL: https://github.com/apache/geode/pull/5587
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
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241114#comment-17241114
]
ASF GitHub Bot commented on GEODE-8419:
---
Bill edited a comment on pull request #5587:
URL: https://github.com/apache/geode/pull/5587#issuecomment-736094657
I'm about to merge this. Since it has sat for almost 8 weeks since the CI
run was last completed, I rebased it locally to test the build (that passed.)
Will wait for this CI build to complete but I won't wait for all the tests to
run again before merging. Just wanted to ensure no sneaky build errors had
arisen and it appears that none have.
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
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241112#comment-17241112
]
ASF GitHub Bot commented on GEODE-8419:
---
Bill commented on pull request #5587:
URL: https://github.com/apache/geode/pull/5587#issuecomment-736094657
I'm about to merge this. Since it has sat for almost 8 weeks since the CI
run was last completed, I rebased it locally to test the build (that passed.)
Will wait for this CI build to complete but I won't wait for all the tests to
run again before merging. Just wanted to ensure no sneaky conflicts had arisen
and it appears that none have.
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
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8607) Add new API for getting oldest tombstone age.
[ https://issues.apache.org/jira/browse/GEODE-8607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241103#comment-17241103 ] ASF subversion and git services commented on GEODE-8607: Commit b027331aa47e51c492c9a2aab414b6abfb69bd51 in geode's branch refs/heads/feature/GEODE-8419-backport from mhansonp [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b027331 ] GEODE-8607: Adding some test API to get oldest tombstone (#5623) (#5733) - Adding some test API to get oldest tombstone timestamp - Adding some test API for getting the oldest tombstone (cherry picked from commit eb91e9517f579c005c7b69937b8cfced7d3cc37e) (cherry picked from commit 3890db1cd755dfbbd28816055fab2a3f34385542) > Add new API for getting oldest tombstone age. > - > > Key: GEODE-8607 > URL: https://issues.apache.org/jira/browse/GEODE-8607 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.14.0 >Reporter: Mark Hanson >Assignee: Mark Hanson >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.2 > > > It would be handy in diagnosing certain issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8682) update jetty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-8682?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241104#comment-17241104 ] ASF subversion and git services commented on GEODE-8682: Commit 741b0b462193c79fc5965a7789e14a86148d0ca2 in geode's branch refs/heads/feature/GEODE-8419-backport from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=741b0b4 ] GEODE-8682: Bump jetty from 9.4.21.v20190926 to 9.4.33.v20201020 This reverts the previous revert commit 4060542d8162ca466b27269f52dc7a312a2ed257. > update jetty to recommended version > --- > > Key: GEODE-8682 > URL: https://issues.apache.org/jira/browse/GEODE-8682 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > update jetty to > [9.4.33.v20201020|https://mvnrepository.com/artifact/org.eclipse.jetty/jetty-server/9.4.33.v20201020] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8661) Tests only use the latest heavy lifter image
[ https://issues.apache.org/jira/browse/GEODE-8661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241106#comment-17241106 ] ASF subversion and git services commented on GEODE-8661: Commit ed4644f93043b6e460b45387cbb6fd6ad43ac516 in geode's branch refs/heads/feature/GEODE-8419-backport from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ed4644f ] [GEODE-8661] Use version provided by *-builder-image-family. (#5681) (cherry picked from commit 828e84dec4be132314f4f99b3644c377fae1171b) (cherry picked from commit 3728eb2efa6abb71287a42c668f1d9a0077dd2f2) > Tests only use the latest heavy lifter image > > > Key: GEODE-8661 > URL: https://issues.apache.org/jira/browse/GEODE-8661 > Project: Geode > Issue Type: Bug > Components: ci >Reporter: Sean Goller >Assignee: Sean Goller >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.2 > > > Test jobs should pay attention to the version of the heavy-lifter image > that's being passed to them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241102#comment-17241102
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/feature/GEODE-8419-backport from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
>
[jira] [Commented] (GEODE-8718) upgrade Shiro to 1.7.0
[ https://issues.apache.org/jira/browse/GEODE-8718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241105#comment-17241105 ] ASF subversion and git services commented on GEODE-8718: Commit 3d929034e9f06041e93b592b0fb18fb8a8e29c13 in geode's branch refs/heads/feature/GEODE-8419-backport from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3d92903 ] GEODE-8718: Bump shiro from 1.6.0 to 1.7.0 > upgrade Shiro to 1.7.0 > -- > > Key: GEODE-8718 > URL: https://issues.apache.org/jira/browse/GEODE-8718 > Project: Geode > Issue Type: Bug > Components: management >Affects Versions: 1.12.0, 1.13.0, 1.14.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.1, 1.14.0, 1.13.2 > > > Our current Shiro version (1.6.0) is below the recommended version. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7884) server hangs due to IllegalStateException
[
https://issues.apache.org/jira/browse/GEODE-7884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241101#comment-17241101
]
ASF subversion and git services commented on GEODE-7884:
Commit 6fec62ff7b4b6ebc4f0f8079fcd67a2b0c3919b0 in geode's branch
refs/heads/feature/GEODE-8419-backport from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=6fec62f ]
GEODE-7884: server hangs due to IllegalStateException (#4822)
* GEODE-7884: server hangs due to IllegalStateException
Added cancellation check before scheduling an idle-timeout or
ack-wait-threshold timer task. I had to add a new method to
SystemTimerTask and then noticed there were no tests for SystemTimer, so
I cleaned up that class and added tests.
* adding missing copyright header to new test
* fixing LGTM issues
* reinstating 'continue' when encountering a null timer during a sweep
* addressing Bill's comments
renamed swarm everwhere
made the collection of timers associated with a DistributedSystem into a Set
made timer task variables in Connection volatile
added checks in tasks to cancel themselves if their Connection is closed
(cherry picked from commit 2d2a3f80bd5053749963889c1898df48e9aa0be7)
> server hangs due to IllegalStateException
> -
>
> Key: GEODE-7884
> URL: https://issues.apache.org/jira/browse/GEODE-7884
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.13.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> An application hung on a cache operation:
> {noformat}
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf61617b8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:731)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:802)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:779)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:865)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeUpdate(DistributedRegion.java:514)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicPutPart3(DistributedRegion.java:492)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.doAfterCompletionActions(RegionMapPut.java:307)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.doPut(AbstractRegionMapPut.java:185)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut$$Lambda$243/1152982325.run(Unknown
> Source)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.runWhileLockedForCacheModification(AbstractRegionMapPut.java:119)
> at
> org.apache.geode.internal.cache.map.RegionMapPut.runWhileLockedForCacheModification(RegionMapPut.java:161)
> at
> org.apache.geode.internal.cache.map.AbstractRegionMapPut.put(AbstractRegionMapPut.java:169)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2044)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5602)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:387)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5580)
> at
>
[jira] [Commented] (GEODE-8419) SSL/TLS protocol and cipher suite configuration is ignored
[
https://issues.apache.org/jira/browse/GEODE-8419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241108#comment-17241108
]
ASF subversion and git services commented on GEODE-8419:
Commit 467ee63578b136c4fd58becaaddc2e274138253b in geode's branch
refs/heads/feature/GEODE-8419-backport from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=467ee63 ]
GEODE-8419: SSL/TLS protocol and cipher suite configuration is ignored (#5465)
Configure cipher suites when creating an SSLEngine
(cherry picked from commit 537721ff815cf40eff85fde65db9b5e787471c89)
> SSL/TLS protocol and cipher suite configuration is ignored
> --
>
> Key: GEODE-8419
> URL: https://issues.apache.org/jira/browse/GEODE-8419
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership, security
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Jacob Barrett
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0, 1.13.1
>
>
> Configuring {{ssl-protocols}} or {{ssl-ciphers}} properties, or per-component
> ssl properties, have no effect. Configuring {{ssl-protocols}} may effect the
> {{SSLContext}} selected and limit some of the protocols allowed but does not
> restrict to just the set specified in the property. The {{ssl-ciphers}}
> property does not limit cipher selection at all.
> The result is that all ciphers allowed under the match {{SSLContext}} are
> allowed and negotiated. This can result in an unintended cipher being used in
> SSL/TLS communication.
--
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=17241107#comment-17241107 ] ASF subversion and git services commented on GEODE-8725: Commit 1d0cd586730ce094caae2a574f2660873994ad86 in geode's branch refs/heads/feature/GEODE-8419-backport 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-8686) Tombstone removal optimization during GII could cause deadlock
[
https://issues.apache.org/jira/browse/GEODE-8686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241100#comment-17241100
]
ASF subversion and git services commented on GEODE-8686:
Commit 7ef68026ee7dea9148eacb79976bf22cd8558fdf in geode's branch
refs/heads/feature/GEODE-8419-backport from Donal Evans
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7ef6802 ]
GEODE-8686: Prevent potential deadlock during GII and tombstone GC (#5707)
- Do not call AbstractRegionMap.removeTombstone() outside of
TombstoneService class
- Add test to confirm that tombstones are correctly scheduled and
collected with this change
Authored-by: Donal Evans
(cherry picked from commit 70b1ee8b98f1458620539c4a962e82f8ef35707b)
> Tombstone removal optimization during GII could cause deadlock
> --
>
> Key: GEODE-8686
> URL: https://issues.apache.org/jira/browse/GEODE-8686
> Project: Geode
> Issue Type: Improvement
>Affects Versions: 1.10.0, 1.11.0, 1.12.0, 1.13.0, 1.14.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.1, 1.14.0, 1.13.1
>
>
> Similar to the issue described in GEODE-6526, if the condition in the below
> if statement in {{AbstractRegionMap.initialImagePut()}} evaluates to true, a
> call to {{AbstractRegionMap.removeTombstone()}} will be triggered that could
> lead to deadlock between the calling thread and a Tombstone GC thread calling
> {{TombstoneService.gcTombstones()}}.
> {code:java}
> if (owner.getServerProxy() == null &&
> owner.getVersionVector().isTombstoneTooOld( entryVersion.getMemberID(),
> entryVersion.getRegionVersion())) {
> // the received tombstone has already been reaped, so don't retain it
> if (owner.getIndexManager() != null) {
> owner.getIndexManager().updateIndexes(oldRe, IndexManager.REMOVE_ENTRY,
> IndexProtocol.REMOVE_DUE_TO_GII_TOMBSTONE_CLEANUP);
> }
> removeTombstone(oldRe, entryVersion, false, false);
> return false;
> } else {
> owner.scheduleTombstone(oldRe, entryVersion);
> lruEntryDestroy(oldRe);
> }
> {code}
> The proposed change is to remove this if statement and allow the old
> tombstone to be collected later by calling {{scheduleTombstone()}} in all
> cases. The call to {{AbstractRegionMap.removeTombstone()}} in
> {{AbstractRegionMap.initialImagePut()}} is intended to be an optimization to
> allow immediate removal of tombstones that we know have already been
> collected on other members, but since the conditions to trigger it are rare
> (the old entry must be a tombstone, the new entry received during GII must be
> a tombstone with a newer version, and we must have already collected a
> tombstone with a newer version than the new entry) and the overhead of
> scheduling a tombstone to be collected is comparatively low, the performance
> impact of removing this optimization in favour of simply scheduling the
> tombstone to be collected in all cases should be insignificant.
> The solution to the deadlock observed in GEODE-6526 was also to remove the
> call to {{AbstractRegionMap.removeTombstone()}} and allow the tombstone to be
> collected later and did not result in any unwanted behaviour, so the proposed
> fix should be similarly low-impact.
> Also of note is that with this proposed change, there will be no calls to
> {{AbstractRegionMap.removeTombstone()}} outside of the {{TombstoneService}}
> class, which should ensure that other deadlocks involving this method are not
> possible.
--
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=17241098#comment-17241098
]
ASF GitHub Bot commented on GEODE-7489:
---
bschuchardt opened a new pull request #5783:
URL: https://github.com/apache/geode/pull/5783
CoreOnlyUsesMembershipAPIArchUnitTest already restricts use of the
membership API to certain classes and does so in a way that avoids using
too much memory. Consequently we're removing this test that needs
upwards of 1.5gb of heap since it performs nearly the same test but
for a specific class in the API package instead of the whole package.
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
> 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] [Created] (GEODE-8747) Collect library dependencies into single dependency
Udo Kohlmeyer created GEODE-8747:
Summary: Collect library dependencies into single dependency
Key: GEODE-8747
URL: https://issues.apache.org/jira/browse/GEODE-8747
Project: Geode
Issue Type: New Feature
Components: build
Reporter: Udo Kohlmeyer
Library dependencies like Spring, Jackson, Spring Security, etc. usually have
many dependencies. Which if used within a module, require the listing each of
these dependencies.
With the addition of ClassLoader Isolation a need arose, where these libraries
where loaded into a single ClassLoader, instead of being loaded by the
ClassLoaders of each of the modules that depended on these libraries.
This feature is to replace the following:
{code:groovy}
implementation('org.springframework:spring-core')
implementation('org.springframework:spring-beans')
implementation('org.springframework:spring-context')
implementation('org.springframework:spring-jcl')
implementation('org.springframework:spring-web')
implementation('org.springframework.shell:spring-shell')
{code}
with a single entry:
{code:groovy}
implementation(project(':frameworks:springframework'))
{code}
What this new construct allows for is a pattern closer to "using a framework"
without having to explicitly define all the library dependencies. In this
approach, we "use" a framework library, rather than knowing all of the internal
dependencies.
With this change, the ClassLoader isolation work, will only load each
dependency once.
Currently identified dependencies that require to be loaded only once are:
Spring and Jackson
--
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=17241085#comment-17241085
]
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_r532930752
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringProcess.java
##
@@ -33,73 +31,86 @@
public class ThreadsMonitoringProcess extends TimerTask {
- private final ThreadsMonitoring threadsMonitoring;
- private ResourceManagerStats resourceManagerStats = null;
private static final Logger logger = LogService.getLogger();
+
+ private final ThreadsMonitoring threadsMonitoring;
private final int timeLimit;
private final InternalDistributedSystem internalDistributedSystem;
- private final Properties nonDefault = new Properties();
- private final DistributionConfigImpl distributionConfigImpl =
- new DistributionConfigImpl(nonDefault);
+ private ResourceManagerStats resourceManagerStats = null;
protected ThreadsMonitoringProcess(ThreadsMonitoring tMonitoring,
- InternalDistributedSystem iDistributedSystem) {
-this.timeLimit = this.distributionConfigImpl.getThreadMonitorTimeLimit();
+ InternalDistributedSystem iDistributedSystem, int timeLimit) {
Review comment:
I changed the name to timeLimitMillis. This unit is determined by an
external geode property so it will always be milliseconds
##
File path:
geode-core/src/test/java/org/apache/geode/internal/monitoring/ThreadsMonitoringProcessJUnitTest.java
##
@@ -34,11 +31,13 @@
*/
public class ThreadsMonitoringProcessJUnitTest {
+ private static final int TIME_LIMIT = 1000;
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
> 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-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=17241083#comment-17241083
]
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_r532929942
##
File path:
geode-core/src/test/java/org/apache/geode/internal/monitoring/executor/P2PReaderExecutorGroupJUnitTest.java
##
@@ -0,0 +1,53 @@
+/*
+ * 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.monitoring.executor;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.junit.Test;
+
+public class P2PReaderExecutorGroupJUnitTest {
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
> 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-7672) Partitioned Region clear will successfully update the OQL indexes
[ https://issues.apache.org/jira/browse/GEODE-7672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jianxia Chen resolved GEODE-7672. - Resolution: Fixed > Partitioned Region clear will successfully update the OQL indexes > - > > Key: GEODE-7672 > URL: https://issues.apache.org/jira/browse/GEODE-7672 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successfully updates the OQL indexes > > Acceptance : > * Passing Dunit tests where OQL queries using indexes return correct results > after the region is cleared > * clear operation and index updates are successful when clear operation is > executed when the puts are occurring which are trying to update the OQL index. > * Unit tests to ensure that index sizes are zero after the region is cleaned > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > > analyze if these tests are needed for offheap? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241072#comment-17241072 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans opened a new pull request #5782: URL: https://github.com/apache/geode/pull/5782 …(#5764) Authored-by: Donal Evans (cherry picked from commit 790af0d473bbe2444fb896d8b77c64116c463774) 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 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241073#comment-17241073 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans opened a new pull request #5781: URL: https://github.com/apache/geode/pull/5781 …(#5764) Authored-by: Donal Evans (cherry picked from commit 790af0d473bbe2444fb896d8b77c64116c463774) 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 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-8614.
---
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are running low on memory
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote
> server.
> {noformat}
> Idea would be to modify *ThinClientRegion::handleServerException* in order to
> return a new error and later on, map it to a new created exception
> *Suggestions*
> The new exception could be called:
> * CacheServerLowMemoryException
> * ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-8614.
-
Fix Version/s: 1.14.0
Resolution: Fixed
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are running low on memory
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote
> server.
> {noformat}
> Idea would be to modify *ThinClientRegion::handleServerException* in order to
> return a new error and later on, map it to a new created exception
> *Suggestions*
> The new exception could be called:
> * CacheServerLowMemoryException
> * ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241054#comment-17241054
]
ASF GitHub Bot commented on GEODE-8614:
---
pdxcodemonkey merged pull request #688:
URL: https://github.com/apache/geode-native/pull/688
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
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are running low on memory
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote
> server.
> {noformat}
> Idea would be to modify *ThinClientRegion::handleServerException* in order to
> return a new error and later on, map it to a new created exception
> *Suggestions*
> The new exception could be called:
> * CacheServerLowMemoryException
> * ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8614) Provide an specific client-side exception for server LowMemoryException
[
https://issues.apache.org/jira/browse/GEODE-8614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241053#comment-17241053
]
ASF subversion and git services commented on GEODE-8614:
Commit b74f474becb328d24cd998c8480756c079d9e7d7 in geode-native's branch
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=b74f474 ]
GEODE-8614: Add LowMemoryException exceptions (#688)
- Refactored Excepion types so:
* Free-functions are now in an anonymous namespace.
* Error map is not initialized each time GfErrTypeThrowException is called.
* Error map is not an static global variable, rather than an static variable
the scope of a free-function.
- Replaced exception construction style by C++11 one.
- Added a new LowMemoryException to be thrown in the client whenever one of the
servers throw such exception.
- Added an integration test which verifies that whenever the
critical-heap-percentage percentage is reached, a LowMemoryException is
thrown in the client.
- Added UT to verify error to exception translation.
- Added query-equivalent to LowMemoryException, so whenever a query is
executed and the server is running low on memory, a
QueryExecutionLowMemoryException is thrown in the client.
> Provide an specific client-side exception for server LowMemoryException
> ---
>
> Key: GEODE-8614
> URL: https://issues.apache.org/jira/browse/GEODE-8614
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS AN* native client contributor
> *I WANT* to have a client-side exception for LowMemoryException
> *SO THAT* I can nofity accordingly from the client-side upon server
> memory-depletion.
> —
> *Additional information*
> This is the callstack of the LowMemoryException:
> {noformat}
> [error 2020/10/13 09:54:14.401405 UTC 140522117220352] Region::put: An
> exception (org.apache.geode.cache.LowMemoryException: PartitionedRegion:
> /part_a cannot process operation on key foo|0 because members
> [192.168.240.14(dms-server-1:1):41000] are running low on memory
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.checkIfBucketSick(RegionAdvisor.java:482)
> at
> org.apache.geode.internal.cache.PartitionedRegion.checkIfAboveThreshold(PartitionedRegion.java:2278)
> at
> org.apache.geode.internal.cache.PartitionedRegion.putInBucket(PartitionedRegion.java:2982)
> at
> org.apache.geode.internal.cache.PartitionedRegion.virtualPut(PartitionedRegion.java:2212)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5573)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5533)
> at
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5212)
> at
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:411)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834) ) happened at remote
> server.
> {noformat}
> Idea would be to modify *ThinClientRegion::handleServerException* in order to
> return a new error and later on, map it to a new created exception
> *Suggestions*
> The new exception could be called:
> * CacheServerLowMemoryException
> * ...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241031#comment-17241031 ] ASF subversion and git services commented on GEODE-8734: Commit 790af0d473bbe2444fb896d8b77c64116c463774 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=790af0d ] GEODE-8734: Parse netstat file to ensure correct stats are retrieved (#5764) Authored-by: Donal Evans > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
[ https://issues.apache.org/jira/browse/GEODE-8734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241030#comment-17241030 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans merged pull request #5764: URL: https://github.com/apache/geode/pull/5764 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 > LinuxProcFsStatistics.getNetStatStats() may incorrectly parse > /proc/net/netstat file > > > Key: GEODE-8734 > URL: https://issues.apache.org/jira/browse/GEODE-8734 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.12.1, 1.14.0, 1.13.1 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: pull-request-available > > The current implementation of the LinuxProcFsStatistics.getNetStatStats() > method assumes a particular ordering of stats within the /proc/net/netstat > file on Linux systems and uses that assumption to parse the contents of the > file when writing to the stats. However, different versions of Linux produce > /proc/net/netstat files with the stats in different positions in the file, > causing the incorrect stat values to be parsed and written to Geode stats, so > a more robust approach is needed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7675) Partitioned Region clear should be successful when clients are present with subscription enabled
[ https://issues.apache.org/jira/browse/GEODE-7675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-7675: Assignee: Jinmei Liao > Partitioned Region clear should be successful when clients are present with > subscription enabled > > > Key: GEODE-7675 > URL: https://issues.apache.org/jira/browse/GEODE-7675 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Jinmei Liao >Priority: Major > Labels: GeodeCommons, pull-request-available > > Clear operations are successful when Client Subscriptions are enabled and > clients are updated with the correct region clear event. > > Acceptance : > * DUnit tests ensuring that clear operations are successful > * Ensure that all clients are getting the correct event notifications. > * HA enabled tests > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7685) Add backward compatibility tests for PartitionedRegion clear
[ https://issues.apache.org/jira/browse/GEODE-7685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-7685: - Labels: GeodeCommons GeodeOperationAPI pull-request-available (was: GeodeCommons pull-request-available) > Add backward compatibility tests for PartitionedRegion clear > > > Key: GEODE-7685 > URL: https://issues.apache.org/jira/browse/GEODE-7685 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI, pull-request-available > > Partitioned region clear must gracefully reject the operation request if > there are older version of Apache Geode are present in the cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7668) Test coverage for PartitionedRegion clear with Persistence enabled
[ https://issues.apache.org/jira/browse/GEODE-7668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-7668: - Labels: GeodeCommons GeodeOperationAPI (was: GeodeCommons) > Test coverage for PartitionedRegion clear with Persistence enabled > --- > > Key: GEODE-7668 > URL: https://issues.apache.org/jira/browse/GEODE-7668 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI > > Using TDD ensure that clear operations are successful when the partitioned > regions have persistence. > Make the code changes required to pass tests. > > Acceptance : > * Passing DUnit tests where clear operations are successful on partitioned > region with persistence enabled. > * These tests should have redundancy of more than zero > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[
https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241022#comment-17241022
]
ASF GitHub Bot commented on GEODE-7739:
---
kirklund commented on a change in pull request #5778:
URL: https://github.com/apache/geode/pull/5778#discussion_r532882325
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/ManagementCacheListener.java
##
@@ -109,8 +108,15 @@ public void afterUpdate(EntryEvent event) {
}
- void markReady() {
-readyForEvents = true;
+ private void blockUntilReady() {
+try {
+ readyForEvents.await();
+} catch (InterruptedException e) {
+ // ignored
Review comment:
Anytime you catch an InterruptedException, you should reset the
interrupt bit unless the thread is locally owned and it will actually terminate
when interrupted:
```
try {
readyForEvents.await();
} catch (InterruptedException e) {
Thread.interrupt();
// recommended: throw new RunnableException(e); -- use an appropriate
GemFire exception here
}
```
@upthewaterspout wrote an article but about this but I'm not sure where it
is.
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/NotificationCacheListener.java
##
@@ -15,100 +15,47 @@
package org.apache.geode.management.internal;
+import java.util.concurrent.CountDownLatch;
+
import javax.management.Notification;
-import org.apache.geode.cache.CacheListener;
import org.apache.geode.cache.EntryEvent;
-import org.apache.geode.cache.RegionEvent;
+import org.apache.geode.cache.util.CacheListenerAdapter;
/**
* This listener will be attached to each notification region corresponding to
a member
- *
*/
-public class NotificationCacheListener implements
CacheListener {
-
- /**
- * For the
- */
- private NotificationHubClient notifClient;
+public class NotificationCacheListener extends
CacheListenerAdapter {
- private volatile boolean readyForEvents;
+ private final NotificationHubClient notifClient;
+ private final CountDownLatch readyForEvents;
public NotificationCacheListener(MBeanProxyFactory proxyHelper) {
-
notifClient = new NotificationHubClient(proxyHelper);
-this.readyForEvents = false;
-
+this.readyForEvents = new CountDownLatch(1);
}
@Override
public void afterCreate(EntryEvent event) {
-if (!readyForEvents) {
- return;
-}
+blockUntilReady();
notifClient.sendNotification(event);
-
- }
-
- @Override
- public void afterDestroy(EntryEvent event) {
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterInvalidate(EntryEvent event)
{
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterRegionClear(RegionEvent
event) {
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterRegionCreate(RegionEvent
event) {
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterRegionDestroy(RegionEvent
event) {
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterRegionInvalidate(RegionEvent
event) {
-// TODO Auto-generated method stub
-
- }
-
- @Override
- public void afterRegionLive(RegionEvent
event) {
-// TODO Auto-generated method stub
-
}
@Override
public void afterUpdate(EntryEvent event) {
-if (!readyForEvents) {
- return;
-}
+blockUntilReady();
notifClient.sendNotification(event);
-
}
- @Override
- public void close() {
-// TODO Auto-generated method stub
-
+ private void blockUntilReady() {
+try {
+ readyForEvents.await();
Review comment:
Same problems as described for ManagementCacheListener apply here.
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/ManagementCacheListener.java
##
@@ -109,8 +108,15 @@ public void afterUpdate(EntryEvent event) {
}
- void markReady() {
-readyForEvents = true;
+ private void blockUntilReady() {
+try {
+ readyForEvents.await();
+} catch (InterruptedException e) {
+ // ignored
Review comment:
Also: If you don't rethrow the InterruptedException within a runtime
exception, then this code probably needs to perform some sort of loop that
checks a CancelCriterion. Grepping 'catch (InterruptedException' on the Geode
product code (not tests) should give some good examples.
##
File path:
geode-core/src/main/java/org/apache/geode/management/internal/ManagementCacheListener.java
##
@@ -33,20 +35,18 @@
private static final Logger logger = LogService.getLogger();
- private MBeanProxyFactory proxyHelper;
+ private final MBeanProxyFactory proxyHelper;
- private volatile boolean readyForEvents;
+ private final CountDownLatch readyForEvents;
Review comment:
The latch should probably be an instance
[jira] [Resolved] (GEODE-7678) Partitioned Region clear operations must invoke cache level listeners
[ https://issues.apache.org/jira/browse/GEODE-7678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-7678. -- Fix Version/s: 1.14.0 Resolution: Fixed > Partitioned Region clear operations must invoke cache level listeners > - > > Key: GEODE-7678 > URL: https://issues.apache.org/jira/browse/GEODE-7678 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Nabarun Nag >Assignee: Anilkumar Gingade >Priority: Major > Labels: GeodeCommons, GeodeOperationAPI > Fix For: 1.14.0 > > > Clear operations are successful and CacheListener.afterRegionClear(), > CacheWriter.beforeRegionClear() are invoked. > > Acceptance : > * DUnit tests validating the above behavior. > * Test coverage to when a member departs in this scenario > * Test coverage to when a member restarts in this scenario > * Unit tests with complete code coverage for the newly written code. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7847) Clear in PR could fail with Partial result, need to send to caller with an exception
[ https://issues.apache.org/jira/browse/GEODE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade resolved GEODE-7847. -- Fix Version/s: 1.14.0 Resolution: Fixed > Clear in PR could fail with Partial result, need to send to caller with an > exception > > > Key: GEODE-7847 > URL: https://issues.apache.org/jira/browse/GEODE-7847 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > Fix For: 1.14.0 > > > In the case of PartitionOfflineException, clear will fail with some of the > buckets cleared, some are not. Need to send back the caller with partial > result exception and let the caller to decide if to retry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7847) Clear in PR could fail with Partial result, need to send to caller with an exception
[ https://issues.apache.org/jira/browse/GEODE-7847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17241014#comment-17241014 ] Anilkumar Gingade commented on GEODE-7847: -- This is addressed as part of https://issues.apache.org/jira/browse/GEODE-7678 > Clear in PR could fail with Partial result, need to send to caller with an > exception > > > Key: GEODE-7847 > URL: https://issues.apache.org/jira/browse/GEODE-7847 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Xiaojian Zhou >Priority: Major > Labels: GeodeCommons > > In the case of PartitionOfflineException, clear will fail with some of the > buckets cleared, some are not. Need to send back the caller with partial > result exception and let the caller to decide if to retry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (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:all-tabpanel
]
Jinmei Liao resolved GEODE-8623.
Fix Version/s: 1.14.0
Resolution: Fixed
> 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
> Fix For: 1.14.0
>
>
> 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.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.724 UTC tid=0x1]
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> Exception in thread "main" 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
>
[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=17240995#comment-17240995
]
ASF subversion and git services commented on GEODE-8623:
Commit 5deb409fe5498845b1365463b11f7a8d558c55f7 in geode's branch
refs/heads/develop from Jinmei Liao
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5deb409 ]
GEODE-8623: Retry getting local host if it fails. (#5743)
Co-authored-by: Jacob Barrett
> 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.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.724 UTC tid=0x1]
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> Exception in thread "main" 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
[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=17240993#comment-17240993
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao merged pull request #5743:
URL: https://github.com/apache/geode/pull/5743
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.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:251)
> Caused by: java.net.UnknownHostException
> at
> org.apache.geode.internal.net.SocketCreator.getLocalHost(SocketCreator.java:285)
> at
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:310)
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:131)
> ... 14 more
> [error 2020/09/30 19:50:21.724 UTC tid=0x1]
> org.apache.geode.management.ManagementException: java.net.UnknownHostException
> Exception in thread "main" 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
>
[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=17240991#comment-17240991
]
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_r532847696
##
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:
The usage of `Retry` (as it stands) in this PR, by
`tryToResolveLocalHost()` is fine:
`tryFor(60, SECONDS, 1, SECONDS…`
The difference between (1) and (4) in this case is at most:
(1) last retry at 59 seconds
(4) last retry at 60 seconds
If the purpose of this PR were to make the best possible `Retry` utility, I
might be inclined to continue the deliberation. But since the purpose of this
PR is to retry resolving the localhost address, and the PR does that, my work
is done here.
In the interest of forward progress, I withdraw my change request on this PR.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
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.
> -
>
>
[jira] [Assigned] (GEODE-8634) CI failure: AsyncInvocationTimeoutDistributedTest. get_callable_timeout_includesStackTraceAsCause
[
https://issues.apache.org/jira/browse/GEODE-8634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-8634:
Assignee: Kirk Lund
> CI failure: AsyncInvocationTimeoutDistributedTest.
> get_callable_timeout_includesStackTraceAsCause
> -
>
> Key: GEODE-8634
> URL: https://issues.apache.org/jira/browse/GEODE-8634
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.13.0, 1.14.0
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>Priority: Major
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/DistributedTestOpenJDK8/builds/24
> {noformat}
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest >
> get_callable_timeout_includesStackTraceAsCause FAILED
> java.lang.AssertionError:
> Expecting message to be:
> <"Stack trace for vm-0 thread-32">
> but was:
> <"Stack trace for vm-0 thread-33">
> Throwable that failed the check:
> org.apache.geode.test.dunit.internal.StackTrace: Stack trace for vm-0
> thread-33
> at sun.misc.Unsafe.park(Native Method)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.lambda$get_callable_timeout_includesStackTraceAsCause$c2252e51$1(AsyncInvocationTimeoutDistributedTest.java:109)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest$$Lambda$36/681142003.call(Unknown
> Source)
> at
> org.apache.geode.test.dunit.internal.IdentifiableCallable.call(IdentifiableCallable.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> at
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:78)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:573)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:834)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:688)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler$$Lambda$15/1238667039.run(Unknown
> Source)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:687)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at
> org.apache.geode.test.dunit.tests.AsyncInvocationTimeoutDistributedTest.get_callable_timeout_includesStackTraceAsCause(AsyncInvocationTimeoutDistributedTest.java:124)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.1-build.0380/test-results/distributedTest/1603276549/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.1-build.0380/test-artifacts/1603276549/distributedtestfiles-OpenJDK8-1.13.1-build.0380.tgz
--
This message was sent by Atlassian Jira
[jira] [Commented] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240986#comment-17240986 ] ASF GitHub Bot commented on GEODE-8746: --- onichols-pivotal opened a new pull request #5779: URL: https://github.com/apache/geode/pull/5779 WIP do not review I am using this PR to attempt to isolate whether a single dependency bump explains why these JDK8 unit tests pass on develop but not 1.13 with latest ubuntu containing jdk1.8.0_275 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 > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- 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=17240987#comment-17240987
]
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_r532833771
##
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:
After talking to @jinmeiliao and thinking about this some more I think
the current implementation (nanosecond units) is ok.
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.distributed.ServerLauncher.createCache(ServerLauncher.java:887)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:803)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:732)
> at
>
[jira] [Updated] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
[ https://issues.apache.org/jira/browse/GEODE-8746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8746: -- Labels: pull-request-available (was: ) > unit tests fail in 1.13 on latest bionic jdk8 build 275 > --- > > Key: GEODE-8746 > URL: https://issues.apache.org/jira/browse/GEODE-8746 > Project: Geode > Issue Type: Bug > Components: ci >Affects Versions: 1.13.1 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > the symptom resembles GEODE-2896, but creating a separate ticket for this new > occurrence... > since the same bionic/jdk image does not cause problems in 1.14, perhaps a > dependency bump is needed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-2896) CI Failure: ClassCastException in GMSMembershipManagerJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240981#comment-17240981
]
Owen Nichols commented on GEODE-2896:
-
created a separate ticket for this new occurrence: GEODE-2896
> CI Failure: ClassCastException in GMSMembershipManagerJUnitTest
>
>
> Key: GEODE-2896
> URL: https://issues.apache.org/jira/browse/GEODE-2896
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Nabarun Nag
>Priority: Major
> Labels: ci
>
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureDueToForcedDisconnect FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect(GMSMembershipManagerJUnitTest.java:343)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testStartupEvents FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testStartupEvents(GMSMembershipManagerJUnitTest.java:219)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testSendToEmptyListIsRejected FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendToEmptyListIsRejected(GMSMembershipManagerJUnitTest.java:177)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendAllRecipients FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients(GMSMembershipManagerJUnitTest.java:331)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSend FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSend(GMSMembershipManagerJUnitTest.java:281)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureToOneRecipient FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient(GMSMembershipManagerJUnitTest.java:294)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureToAll FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToAll(GMSMembershipManagerJUnitTest.java:313)
>
[jira] [Comment Edited] (GEODE-2896) CI Failure: ClassCastException in GMSMembershipManagerJUnitTest
[
https://issues.apache.org/jira/browse/GEODE-2896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240981#comment-17240981
]
Owen Nichols edited comment on GEODE-2896 at 11/30/20, 7:02 PM:
created a separate ticket for this new occurrence: GEODE-8746
was (Author: onichols-pivotal):
created a separate ticket for this new occurrence: GEODE-2896
> CI Failure: ClassCastException in GMSMembershipManagerJUnitTest
>
>
> Key: GEODE-2896
> URL: https://issues.apache.org/jira/browse/GEODE-2896
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Nabarun Nag
>Priority: Major
> Labels: ci
>
> {noformat}
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureDueToForcedDisconnect FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureDueToForcedDisconnect(GMSMembershipManagerJUnitTest.java:343)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testStartupEvents FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testStartupEvents(GMSMembershipManagerJUnitTest.java:219)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testSendToEmptyListIsRejected FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testSendToEmptyListIsRejected(GMSMembershipManagerJUnitTest.java:177)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendAllRecipients FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendAllRecipients(GMSMembershipManagerJUnitTest.java:331)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSend FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSend(GMSMembershipManagerJUnitTest.java:281)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureToOneRecipient FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest.testDirectChannelSendFailureToOneRecipient(GMSMembershipManagerJUnitTest.java:294)
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManagerJUnitTest
> > testDirectChannelSendFailureToAll FAILED
> java.lang.ClassCastException:
> org.apache.geode.distributed.internal.LonerDistributionManager cannot be cast
> to org.apache.geode.distributed.internal.DistributionManager
> at
> org.apache.geode.distributed.internal.HighPriorityAckedMessage.(HighPriorityAckedMessage.java:68)
> at
>
[jira] [Created] (GEODE-8746) unit tests fail in 1.13 on latest bionic jdk8 build 275
Owen Nichols created GEODE-8746: --- Summary: unit tests fail in 1.13 on latest bionic jdk8 build 275 Key: GEODE-8746 URL: https://issues.apache.org/jira/browse/GEODE-8746 Project: Geode Issue Type: Bug Components: ci Affects Versions: 1.13.1 Reporter: Owen Nichols the symptom resembles GEODE-2896, but creating a separate ticket for this new occurrence... since the same bionic/jdk image does not cause problems in 1.14, perhaps a dependency bump is needed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-7739: -- Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI) > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7739) JMX managers may fail to federate mbeans for other members
[ https://issues.apache.org/jira/browse/GEODE-7739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240976#comment-17240976 ] ASF GitHub Bot commented on GEODE-7739: --- jhutchison opened a new pull request #5778: URL: https://github.com/apache/geode/pull/5778 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 > JMX managers may fail to federate mbeans for other members > -- > > Key: GEODE-7739 > URL: https://issues.apache.org/jira/browse/GEODE-7739 > Project: Geode > Issue Type: Bug > Components: jmx >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: GeodeOperationAPI > Time Spent: 20m > Remaining Estimate: 0h > > JMX Manager may fail to federate one or more MXBeans for other members > because of a race condition during startup. When ManagementCacheListener is > first constructed, it is in a state that will ignore all callbacks because > the field readyForEvents is false. > > Debugging with JMXMBeanReconnectDUnitTest revealed this bug. > The test starts two locators with jmx manager configured and started. > Locator1 always has all of locator2's mbeans, but locator2 is intermittently > missing the personal mbeans of locator1. > I think this is caused by some sort of race condition in the code that > creates the monitoring regions for other members in locator2. > It's possible that the jmx manager that hits this bug might fail to have > mbeans for servers as well as other locators but I haven't seen a test case > for this scenario. > The exposure of this bug means that a user running more than one locator > might have a locator that is missing one or more mbeans for the cluster. > > Studying the JMX code also reveals the existence of *GEODE-8012*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8742:
--
Labels: pull-request-available (was: )
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8742) List gateways command doesn't work properly
[
https://issues.apache.org/jira/browse/GEODE-8742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240942#comment-17240942
]
ASF GitHub Bot commented on GEODE-8742:
---
DonalEvans commented on pull request #5777:
URL: https://github.com/apache/geode/pull/5777#issuecomment-735948832
It's possible that these changes may overlap/conflict with
https://github.com/apache/geode/pull/5770. It could be a good idea to rebase
off that branch and confirm that the issue these changes are intended to fix is
still present with the above PR in place.
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
> List gateways command doesn't work properly
> ---
>
> Key: GEODE-8742
> URL: https://issues.apache.org/jira/browse/GEODE-8742
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.13.0, 1.13.1
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> When you create serial gateway sender with dispatcher-threads equals to 1,
> list gateways command will fail.
>
> {code:java}
> Cluster-2 gfsh>list gateways
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --senders-only
> Error while processing command Reason : null
> Cluster-2 gfsh>list gateways --receivers-only
> GatewayReceiver Section
> Member | Port | Sender Count | Senders Connected
> -- | | |
> -
> 192.168.0.145(server-ln-1:27600):41001 | 5094 | 0 |
> 192.168.0.145(server-ln-2:27688):41002 | 5434 | 0 |
>
> {code}
>
> It fails from introducing GEODE-7757, because it now looks on connected state
> also to have more info in list gateways command.
--
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=17240938#comment-17240938 ] ASF GitHub Bot commented on GEODE-8656: --- gesterzhou closed pull request #5775: URL: https://github.com/apache/geode/pull/5775 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 > Fix For: 1.14.0 > > > 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] [Resolved] (GEODE-8743) Revert GEODE-8656 to refix the ClassCastException in rollingUpgrade tests
[ https://issues.apache.org/jira/browse/GEODE-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8743. -- Resolution: Fixed Fix in private test code. > Revert GEODE-8656 to refix the ClassCastException in rollingUpgrade tests > - > > Key: GEODE-8743 > URL: https://issues.apache.org/jira/browse/GEODE-8743 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > GEODE-8656 caused many rollingUpgrade tests failed with ClassCastException. > We have to revert it to refix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8743) Revert GEODE-8656 to refix the ClassCastException in rollingUpgrade tests
[ https://issues.apache.org/jira/browse/GEODE-8743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240934#comment-17240934 ] Xiaojian Zhou commented on GEODE-8743: -- Mark and Anil's fix in private test code looks like to have resolved the issue. I think we don't have to revert it. I agree that for internal class, geode develop should have more freedom to change. Private test code should comply with the change. I will close the ticket. > Revert GEODE-8656 to refix the ClassCastException in rollingUpgrade tests > - > > Key: GEODE-8743 > URL: https://issues.apache.org/jira/browse/GEODE-8743 > Project: Geode > Issue Type: Bug >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Labels: GeodeOperationAPI > > GEODE-8656 caused many rollingUpgrade tests failed with ClassCastException. > We have to revert it to refix it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[
https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240928#comment-17240928
]
ASF GitHub Bot commented on GEODE-8745:
---
DonalEvans commented on a change in pull request #5770:
URL: https://github.com/apache/geode/pull/5770#discussion_r532787287
##
File path:
geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANPersistenceEnabledGatewaySenderDUnitTest.java
##
@@ -603,27 +605,32 @@ public void
testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueue
vm7.invoke(() ->
WANTestBase.createPersistentReplicatedRegion(getTestMethodName() + "_RR", "ln",
isOffHeap()));
+vm4.invoke(() -> WANTestBase.pauseSender("ln"));
+vm5.invoke(() -> WANTestBase.pauseSender("ln"));
+
vm4.invoke(() -> WANTestBase.doPuts(getTestMethodName() + "_RR", 1000));
logger.info("Completed puts in the region");
vm4.invoke(() -> WANTestBase.stopSender("ln"));
vm5.invoke(() -> WANTestBase.stopSender("ln"));
-logger.info("Stopped all the senders. ");
-// Create receiver on remote site
-createReceiverInVMs(vm2, vm3);
+logger.info("Stopped all the senders. ");
Review comment:
Instead of using the logger in this test to track progress, you could
instead use the `invoke()` method signature that passes a String
description/name as the first parameter, which allows anyone debugging the test
to see when the invocation in question starts and finishes. Just personal
preference, but I think it makes things neater and provides a little more
information to anyone looking at the test output.
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
> Closing the region backing the queue when the serial gateway sender is
> stopped.
> ---
>
> Key: GEODE-8745
> URL: https://issues.apache.org/jira/browse/GEODE-8745
> Project: Geode
> Issue Type: Task
> Components: wan
>Reporter: Nabarun Nag
>Priority: Major
> Labels: pull-request-available
>
> In the commit for GEODE-7458, when the sender is stopped, the region backing
> the queues are no more closed, but just remove the cache listeners.
> This is causing a problem, as the regions continue to exist, it keeps on
> storing entry events and hence the queue size never gets to zero.
> Also, as the region exists but before attaching the cache listener when
> restarting the sender leads to entries being never removed from the
> unprocessed event map.
>
> As mention in the PR for GEODE-7458 - "This option is only applicable for
> Gateway Senders with enabled persistence."
> Hence believe that it is ok to close the region as the disk files will still
> be maintained. so when we restart the values can be obtained back from the
> disk stores.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240923#comment-17240923
]
ASF subversion and git services commented on GEODE-8664:
Commit a6942e707881e647b89de945adc38de3076d2da9 in geode's branch
refs/heads/develop from Mario Salazar de Torres
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6942e7 ]
GEODE-8664: Nest errors in DistributionImpl.start (#5751)
- If while calling DistributionImpl.start there was either a
MembershipConfigurationException or MemberStartupException exceptions, its
original cause was not propagated, therefore being unable to properly tackle
issues on startup.
- This commit propagates both exceptions.
- Also 2 junit test were added to make sure this is working.
- Also 2 DUnit tests were modified in order to integrate with this
change.
Note: After having to revert the original change in PR #5725 due to some
issues with the CI system, test have been sorted out and everything
is working.
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240922#comment-17240922
]
ASF GitHub Bot commented on GEODE-8664:
---
bschuchardt commented on pull request #5751:
URL: https://github.com/apache/geode/pull/5751#issuecomment-735939753
Don't forget to resolve the JIRA ticket
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
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
>
[jira] [Commented] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240920#comment-17240920
]
ASF GitHub Bot commented on GEODE-8664:
---
bschuchardt merged pull request #5751:
URL: https://github.com/apache/geode/pull/5751
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
> JGroups exception is not propagated
> ---
>
> Key: GEODE-8664
> URL: https://issues.apache.org/jira/browse/GEODE-8664
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.12.0, 1.13.0
>Reporter: Mario Salazar de Torres
>Assignee: Mario Salazar de Torres
>Priority: Minor
> Labels: pull-request-available
> Attachments: GEODE-8664.patch
>
>
> *AS A* geode contributor
> *I WANT* exceptions thrown in DistributionImpl.start to be propagated
> *SO THAT* more information is provided while tackling issues.
>
>
> *Additional information:*
> After looking at an issue while starting a locator having to do with
> JGroupMessenger I noticed that exceptions from Membership.start are not
> correctly propagated in DistributionImpl.start method.
> To ilustrate the problem I attach below the reported exception while starting
> the locator:
>
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.GemFireConfigException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:184)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3033)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
> at
> org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217){noformat}
>
> Thing is with that kind of information there's no way to know why the problem
> is happening, so the idea would be to propagate the exceptions, so it looks
> more like this:
> {noformat}
> locator is exiting due to an exception
> org.apache.geode.SystemConnectException: unable to create jgroups channel
> at
> org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:186)
> at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:222)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:743)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:388)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
[jira] [Commented] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[
https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240912#comment-17240912
]
ASF GitHub Bot commented on GEODE-8745:
---
nabarunnag commented on a change in pull request #5770:
URL: https://github.com/apache/geode/pull/5770#discussion_r532776796
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderEventProcessor.java
##
@@ -111,10 +111,9 @@ public
SerialGatewaySenderEventProcessor(AbstractGatewaySender sender, String id
ThreadsMonitoring tMonitoring, boolean cleanQueues) {
super("Event Processor for GatewaySender_" + id, sender, tMonitoring);
+initializeMessageQueue(id, cleanQueues);
Review comment:
This change is because the CacheListener to handle the
unprocessedEventsMap is set here, hence I wanted the listener to be up and
running before the map is initialized so the no events are missed because they
were put in the map before the listener was running.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderEventProcessor.java
##
@@ -111,10 +111,9 @@ public
SerialGatewaySenderEventProcessor(AbstractGatewaySender sender, String id
ThreadsMonitoring tMonitoring, boolean cleanQueues) {
super("Event Processor for GatewaySender_" + id, sender, tMonitoring);
+initializeMessageQueue(id, cleanQueues);
Review comment:
This change is because the CacheListener to handle the
unprocessedEventsMap is set here, hence I wanted the listener to be up and
running before the map is initialized so that no events are missed because they
were put in the map before the listener was running.
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
> Closing the region backing the queue when the serial gateway sender is
> stopped.
> ---
>
> Key: GEODE-8745
> URL: https://issues.apache.org/jira/browse/GEODE-8745
> Project: Geode
> Issue Type: Task
> Components: wan
>Reporter: Nabarun Nag
>Priority: Major
>
> In the commit for GEODE-7458, when the sender is stopped, the region backing
> the queues are no more closed, but just remove the cache listeners.
> This is causing a problem, as the regions continue to exist, it keeps on
> storing entry events and hence the queue size never gets to zero.
> Also, as the region exists but before attaching the cache listener when
> restarting the sender leads to entries being never removed from the
> unprocessed event map.
>
> As mention in the PR for GEODE-7458 - "This option is only applicable for
> Gateway Senders with enabled persistence."
> Hence believe that it is ok to close the region as the disk files will still
> be maintained. so when we restart the values can be obtained back from the
> disk stores.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
[ https://issues.apache.org/jira/browse/GEODE-8745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8745: -- Labels: pull-request-available (was: ) > Closing the region backing the queue when the serial gateway sender is > stopped. > --- > > Key: GEODE-8745 > URL: https://issues.apache.org/jira/browse/GEODE-8745 > Project: Geode > Issue Type: Task > Components: wan >Reporter: Nabarun Nag >Priority: Major > Labels: pull-request-available > > In the commit for GEODE-7458, when the sender is stopped, the region backing > the queues are no more closed, but just remove the cache listeners. > This is causing a problem, as the regions continue to exist, it keeps on > storing entry events and hence the queue size never gets to zero. > Also, as the region exists but before attaching the cache listener when > restarting the sender leads to entries being never removed from the > unprocessed event map. > > As mention in the PR for GEODE-7458 - "This option is only applicable for > Gateway Senders with enabled persistence." > Hence believe that it is ok to close the region as the disk files will still > be maintained. so when we restart the values can be obtained back from the > disk stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8745) Closing the region backing the queue when the serial gateway sender is stopped.
Nabarun Nag created GEODE-8745: -- Summary: Closing the region backing the queue when the serial gateway sender is stopped. Key: GEODE-8745 URL: https://issues.apache.org/jira/browse/GEODE-8745 Project: Geode Issue Type: Task Components: wan Reporter: Nabarun Nag In the commit for GEODE-7458, when the sender is stopped, the region backing the queues are no more closed, but just remove the cache listeners. This is causing a problem, as the regions continue to exist, it keeps on storing entry events and hence the queue size never gets to zero. Also, as the region exists but before attaching the cache listener when restarting the sender leads to entries being never removed from the unprocessed event map. As mention in the PR for GEODE-7458 - "This option is only applicable for Gateway Senders with enabled persistence." Hence believe that it is ok to close the region as the disk files will still be maintained. so when we restart the values can be obtained back from the disk stores. -- 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=17240909#comment-17240909 ] ASF GitHub Bot commented on GEODE-8656: --- gesterzhou commented on pull request #5775: URL: https://github.com/apache/geode/pull/5775#issuecomment-735929141 Mark and Naba's fix in private test code looks like to have resolved the issue. I think we don't have to revert it. I agree that for internal class, geode develop should have more freedom to change. Private test code should comply with the change. I will close the PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. 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 > Fix For: 1.14.0 > > > 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-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=17240905#comment-17240905
]
ASF GitHub Bot commented on GEODE-8521:
---
kirklund commented on a change in pull request #5763:
URL: https://github.com/apache/geode/pull/5763#discussion_r532766936
##
File path:
geode-core/src/test/java/org/apache/geode/internal/monitoring/executor/P2PReaderExecutorGroupJUnitTest.java
##
@@ -0,0 +1,53 @@
+/*
+ * 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.monitoring.executor;
+
+import static org.assertj.core.api.Assertions.assertThat;
+
+import org.junit.Test;
+
+public class P2PReaderExecutorGroupJUnitTest {
Review comment:
I recommend just naming unit tests as P2PReaderExecutorGroupTest (no
need to include JUnit)
##
File path:
geode-core/src/test/java/org/apache/geode/internal/monitoring/ThreadsMonitoringProcessJUnitTest.java
##
@@ -34,11 +31,13 @@
*/
public class ThreadsMonitoringProcessJUnitTest {
+ private static final int TIME_LIMIT = 1000;
Review comment:
Please indicate the units of measure in the name or an additional
parameter.
##
File path:
geode-core/src/main/java/org/apache/geode/internal/monitoring/ThreadsMonitoringProcess.java
##
@@ -33,73 +31,86 @@
public class ThreadsMonitoringProcess extends TimerTask {
- private final ThreadsMonitoring threadsMonitoring;
- private ResourceManagerStats resourceManagerStats = null;
private static final Logger logger = LogService.getLogger();
+
+ private final ThreadsMonitoring threadsMonitoring;
private final int timeLimit;
private final InternalDistributedSystem internalDistributedSystem;
- private final Properties nonDefault = new Properties();
- private final DistributionConfigImpl distributionConfigImpl =
- new DistributionConfigImpl(nonDefault);
+ private ResourceManagerStats resourceManagerStats = null;
protected ThreadsMonitoringProcess(ThreadsMonitoring tMonitoring,
- InternalDistributedSystem iDistributedSystem) {
-this.timeLimit = this.distributionConfigImpl.getThreadMonitorTimeLimit();
+ InternalDistributedSystem iDistributedSystem, int timeLimit) {
Review comment:
What unit is timeLimit? I recommend either adding a TimeUnit parameter
or renaming timeLimit to include Millis or something as a prefix.
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-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240873#comment-17240873 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240872#comment-17240872 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240878#comment-17240878 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240879#comment-17240879 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240880#comment-17240880 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240881#comment-17240881 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240876#comment-17240876 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240882#comment-17240882 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240875#comment-17240875 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240874#comment-17240874 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17240877#comment-17240877 ] ASF subversion and git services commented on GEODE-8537: Commit cbe25281938b442be2087adde540935e1985888c in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=cbe2528 ] GEODE-8537: Solve memory increase when LRU eviction is enabled (#687) * GEODE-8537: Refactor LRUList - LRUEntryProperties has been put into a separate file. - LRUList has been entirely refactored. It now uses STL's deque as base implementation. Implements the following methods: * push * pop * remove * move_to_end * size * clear - LRUList has been renamed to LRUQueue. * GEODE-8537: Integrate LRUQueue into LRU entries map - Refactored LRUEntriesMap to integrate with the new implementation of LRUQueue. * GEODE-8537: Fix compilation - After the changes made to both LRUQueue and LRUEntryProperties, compilation was broken. - This commit solves that. * GEODE-8537: Add UTs for LRUQueue - Added UTs for LRUQueue. - Added a mock for MapEntryImpl. - Removed testLRUList from old integration tests as has been replaced by the UT TS. * GEODE-8537: Solve EvictionController malfunction - EvictionController and EvictionThread was causing an inter-lock and also there was a race-condition which made LRU eviction not to be accurate. - In order to solve EvictionController malfunction the following things have been changed: * Now evictions are made by the EvictionController and the EvictionThread has been removed as in addition to the inter-lock, it was causing some unnecessary overhead. * EvictionController queue has been replaced by the heap size itself as an atomic variable. So now, eviction happens directly whenever heap size overflows the established limit, without having to sum up the deltas on the queue. - Additionally heap size counter in the LRUEntriesMap has been replaced by an atomic counter, getting rid therefore of the mutex. * GEODE-8537: Add LRU eviction integration tests - Added a new integrations TS to verify LRU eviction functionality. * GEODE-8537: Remove wrong test from old ITs - After implementing the new LRUQueue I noticed that testRegionMap.TestRecentlyUsedBit was failing and I noticed that the test was wrongly implemented. - Having set LRU entries limit to 10 and getting key "15" you could not expect that after putting keys [20, 35], key "15" would be still there. - Also the test has been replaced by one new integration test called LRUEvictionTest.verifyLruOrderGet * GEODE-8537: Revision 2 - Used mixed case in the EvictionController. - Removed debugging trace which was left during development. * GEODE-8537: Revision 3 - After discussing about the nature of LRUQueue, it seems that std::mutex is a better alternative to make LRUQueue thread-safe, so it's now the mutex used. * GEODE-8537: Re-trigger CI > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-8537) Memory increases whenever LRU eviction is enabled
[ https://issues.apache.org/jira/browse/GEODE-8537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-8537. --- > Memory increases whenever LRU eviction is enabled > - > > Key: GEODE-8537 > URL: https://issues.apache.org/jira/browse/GEODE-8537 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: massif-8419.png, massif.out.8419 > > > *HAVING* configured concurrency-checks-enabled=false in the client-cache.xml > for a region > *HAVING* configured heap-lru-limit=10 in the client-cache.xml for the region > region > *HAVING* configured heap-lru-delta=10 in the client-cache.xml for the region > region > *HAVING* configured subscription-notification for the pool on which the > region is defined > *HAVING* regsitered interest on all the keys of this region, values included > *AFTER* receiving lots of LOCA_CREATE and LOCAL_DESTROY notifications > *THEN* memory increases continously over time, even going over the LRU limit. > Find massif tool report as massif.out.8419 showing the memory increase. > Also this is a capture of massif-visualizer for the report: > !massif-8419.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
