[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&focusedCommentId=17235280#comment-17235280 ] ASF subversion and git services commented on GEODE-8661: Commit 3728eb2efa6abb71287a42c668f1d9a0077dd2f2 in geode's branch refs/heads/support/1.13 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3728eb2 ] [GEODE-8661] Use version provided by *-builder-image-family. (#5681) (cherry picked from commit 828e84dec4be132314f4f99b3644c377fae1171b) > 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.14.0 > > > 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-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&focusedCommentId=17235281#comment-17235281 ] ASF subversion and git services commented on GEODE-8661: Commit 3728eb2efa6abb71287a42c668f1d9a0077dd2f2 in geode's branch refs/heads/support/1.13 from Sean Goller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3728eb2 ] [GEODE-8661] Use version provided by *-builder-image-family. (#5681) (cherry picked from commit 828e84dec4be132314f4f99b3644c377fae1171b) > 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.14.0 > > > 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-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235288#comment-17235288 ] ASF GitHub Bot commented on GEODE-8693: --- codecov-io edited a comment on pull request #690: URL: https://github.com/apache/geode-native/pull/690#issuecomment-728320149 # [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=h1) Report > Merging [#690](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=desc) (a24d8c3) into [develop](https://codecov.io/gh/apache/geode-native/commit/5c7d47d34c2b8a53874ec6f53e66c2290fd0427c?el=desc) (5c7d47d) will **decrease** coverage by `0.04%`. > The diff coverage is `50.00%`. [](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) ```diff @@ Coverage Diff @@ ## develop #690 +/- ## === - Coverage74.12% 74.07% -0.05% === Files 644 644 Lines5118751184 -3 === - Hits 3794237916 -26 - Misses 1324513268 +23 ``` | [Impacted Files](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [cppcache/src/CqQueryImpl.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0NxUXVlcnlJbXBsLmNwcA==) | `56.37% <0.00%> (ø)` | | | [cppcache/src/ExecutionImpl.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0V4ZWN1dGlvbkltcGwuY3Bw) | `69.92% <28.57%> (+1.84%)` | :arrow_up: | | [cppcache/src/ThinClientPoolDM.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRQb29sRE0uY3Bw) | `77.72% <100.00%> (+1.23%)` | :arrow_up: | | [cppcache/src/ThinClientStickyManager.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRTdGlja3lNYW5hZ2VyLmNwcA==) | `77.88% <0.00%> (-10.58%)` | :arrow_down: | | [cppcache/src/TcrEndpoint.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckVuZHBvaW50LmNwcA==) | `54.27% <0.00%> (-2.39%)` | :arrow_down: | | [cppcache/src/TXCommitMessage.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RYQ29tbWl0TWVzc2FnZS5jcHA=) | `74.50% <0.00%> (-1.97%)` | :arrow_down: | | [cppcache/src/TcrConnection.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckNvbm5lY3Rpb24uY3Bw) | `72.48% <0.00%> (-1.26%)` | :arrow_down: | | [cppcache/src/ClientMetadataService.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0NsaWVudE1ldGFkYXRhU2VydmljZS5jcHA=) | `61.78% <0.00%> (-1.15%)` | :arrow_down: | | [...tegration-test/testThinClientRemoteRegionQuery.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvaW50ZWdyYXRpb24tdGVzdC90ZXN0VGhpbkNsaWVudFJlbW90ZVJlZ2lvblF1ZXJ5LmNwcA==) | `82.33% <0.00%> (-1.13%)` | :arrow_down: | | [cppcache/src/Log.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0xvZy5jcHA=) | `56.50% <0.00%> (-0.98%)` | :arrow_down: | | ... and [5 more](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=footer). Last update [5c7d47d...a24d8c3](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). 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 > C++ native client Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > -
[jira] [Created] (GEODE-8729) LGTM analysis in geode-native failing after Geode 1.13.1 has been released
Alberto Gomez created GEODE-8729: Summary: LGTM analysis in geode-native failing after Geode 1.13.1 has been released Key: GEODE-8729 URL: https://issues.apache.org/jira/browse/GEODE-8729 Project: Geode Issue Type: Bug Components: ci, native client Affects Versions: 1.13.0 Reporter: Alberto Gomez After releasing Apache Geode 1.13.1 the LGTM analysis done on PRs is failing because version 1.13.0 has been archived and is no longer available on the mirrors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8729) LGTM analysis in geode-native failing after Geode 1.13.1 has been released
[ https://issues.apache.org/jira/browse/GEODE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Gomez reassigned GEODE-8729: Assignee: Alberto Gomez > LGTM analysis in geode-native failing after Geode 1.13.1 has been released > -- > > Key: GEODE-8729 > URL: https://issues.apache.org/jira/browse/GEODE-8729 > Project: Geode > Issue Type: Bug > Components: ci, native client >Affects Versions: 1.13.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > After releasing Apache Geode 1.13.1 the LGTM analysis done on PRs is failing > because version 1.13.0 has been archived and is no longer available on the > mirrors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8729) LGTM analysis in geode-native failing after Geode 1.13.1 has been released
[ https://issues.apache.org/jira/browse/GEODE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8729: -- Labels: pull-request-available (was: ) > LGTM analysis in geode-native failing after Geode 1.13.1 has been released > -- > > Key: GEODE-8729 > URL: https://issues.apache.org/jira/browse/GEODE-8729 > Project: Geode > Issue Type: Bug > Components: ci, native client >Affects Versions: 1.13.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > After releasing Apache Geode 1.13.1 the LGTM analysis done on PRs is failing > because version 1.13.0 has been archived and is no longer available on the > mirrors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8729) LGTM analysis in geode-native failing after Geode 1.13.1 has been released
[ https://issues.apache.org/jira/browse/GEODE-8729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235363#comment-17235363 ] ASF GitHub Bot commented on GEODE-8729: --- albertogpz opened a new pull request #698: URL: https://github.com/apache/geode-native/pull/698 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 > LGTM analysis in geode-native failing after Geode 1.13.1 has been released > -- > > Key: GEODE-8729 > URL: https://issues.apache.org/jira/browse/GEODE-8729 > Project: Geode > Issue Type: Bug > Components: ci, native client >Affects Versions: 1.13.0 >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > > After releasing Apache Geode 1.13.1 the LGTM analysis done on PRs is failing > because version 1.13.0 has been archived and is no longer available on the > mirrors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8656) Ping not sent to the right gateway receiver endpoint when several receivers have the same hostname-for-senders value
[ https://issues.apache.org/jira/browse/GEODE-8656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235368#comment-17235368 ] ASF GitHub Bot commented on GEODE-8656: --- albertogpz commented on pull request #5670: URL: https://github.com/apache/geode/pull/5670#issuecomment-730321103 > Nice work Alberto. I appreciate that you persevered and added a Dockerized test that exhibits your achievements. > > I wonder if you'd be willing to write something up to contribute to Geode documentation about this use case. Other people could benefit from knowing about this option. > > I do have a couple of minor changes that I'd like to see in the new acceptance test. Thanks @bschuchardt . I agree it would be good to write something in the documentation about this use case. I assume you are talking about WAN deployments in which the topology of the Geode cluster (the servers) is hidden behind a single IP address. Am I correct? If so, I will look for a place in the Geode documentation to add to it. I think it will be best to do it in a new PR. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Ping not sent to the right gateway receiver endpoint when several receivers > have the same hostname-for-senders value > > > Key: GEODE-8656 > URL: https://issues.apache.org/jira/browse/GEODE-8656 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > When several gateway receivers have the same value for hostname-for-senders > (for example when running Geode under kubernetes and a load balancer balances > the load among the remote servers), the ping messages sent from the gateway > sender client are only sent to the receiver (endpoint) to which the sender > connected first. > The other receivers will not get the ping message which will imply that the > connections towards them will be closed after the configured timeout expires. > This ticket is a continuation of the work done ticket GEODE-7565. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[ https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235502#comment-17235502 ] ASF GitHub Bot commented on GEODE-8711: --- sabbey37 merged pull request #5749: URL: https://github.com/apache/geode/pull/5749 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 > Enable SLOWLOG command to support Redis monitoring tools > > > Key: GEODE-8711 > URL: https://issues.apache.org/jira/browse/GEODE-8711 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Priority: Major > Labels: pull-request-available > > The Redis SLOWLOG command tracks slow-executing commands. This will implement > a placeholder to prevent errors in tools like Datadog or Redis Insights. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8725: -- Labels: pull-request-available (was: ) > 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 > > Update Jetty to latest version (9.4.34) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[ https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235504#comment-17235504 ] ASF subversion and git services commented on GEODE-8711: Commit 0b18786dcd274cdbdc681053d0905d4ac8df618e in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0b18786 ] GEODE-8711: Enable SLOWLOG Redis command (#5749) > Enable SLOWLOG command to support Redis monitoring tools > > > Key: GEODE-8711 > URL: https://issues.apache.org/jira/browse/GEODE-8711 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Priority: Major > Labels: pull-request-available > > The Redis SLOWLOG command tracks slow-executing commands. This will implement > a placeholder to prevent errors in tools like Datadog or Redis Insights. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[ https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey reassigned GEODE-8711: -- Assignee: Raymond Ingles > Enable SLOWLOG command to support Redis monitoring tools > > > Key: GEODE-8711 > URL: https://issues.apache.org/jira/browse/GEODE-8711 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > > The Redis SLOWLOG command tracks slow-executing commands. This will implement > a placeholder to prevent errors in tools like Datadog or Redis Insights. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235503#comment-17235503 ] ASF GitHub Bot commented on GEODE-8725: --- jdeppe-pivotal merged pull request #5741: URL: https://github.com/apache/geode/pull/5741 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update 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 > > Update Jetty to latest version (9.4.34) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8711) Enable SLOWLOG command to support Redis monitoring tools
[ https://issues.apache.org/jira/browse/GEODE-8711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8711. Fix Version/s: 1.14.0 Resolution: Fixed > Enable SLOWLOG command to support Redis monitoring tools > > > Key: GEODE-8711 > URL: https://issues.apache.org/jira/browse/GEODE-8711 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.14.0 >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The Redis SLOWLOG command tracks slow-executing commands. This will implement > a placeholder to prevent errors in tools like Datadog or Redis Insights. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235505#comment-17235505 ] ASF subversion and git services commented on GEODE-8725: Commit 57ff1b785a753ef509234868aaa6290c9a6576f7 in geode's branch refs/heads/develop from Sarah [ https://gitbox.apache.org/repos/asf?p=geode.git;h=57ff1b7 ] GEODE-8725: Update Jetty to 9.4.34 (#5741) > 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 > > Update Jetty to latest version (9.4.34) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8725) Update Jetty to 9.4.34
[ https://issues.apache.org/jira/browse/GEODE-8725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey resolved GEODE-8725. Fix Version/s: 1.14.0 Resolution: Fixed > 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-8724) Fix compilation using geode-native docker image
[ https://issues.apache.org/jira/browse/GEODE-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235561#comment-17235561 ] ASF GitHub Bot commented on GEODE-8724: --- pivotal-jbarrett commented on pull request #696: URL: https://github.com/apache/geode-native/pull/696#issuecomment-730472991 I pushed a new image last night. 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 > Fix compilation using geode-native docker image > --- > > Key: GEODE-8724 > URL: https://issues.apache.org/jira/browse/GEODE-8724 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > As geode-native was re-built and re-uploaded, it's now using the latest > version of ubuntu, which is 20.04 as of some months. > Thing is docker builds started to fail after uploading the new docker image. > This task is intended to look into the issue and propose one/several > solutions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235562#comment-17235562 ] ASF GitHub Bot commented on GEODE-8700: --- pivotal-jbarrett commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-730476801 I am not sure I understand the motivation. Are you saying that you want to define the region in `cache.xml` and then later mutate it from the API? I am not sure how safe this would be given the general immutable nature of the region objects. What is the motivation to split the configuration this way. Our general recommendation is to use the API over the XML configuration anyway. The server is moving away from the XML configuration to cluster config and API config. The API provides the ability to provide an instantiated by the call instance of the resolver where the API must use "reflection" of sorts to new one up so context is disconnected with the application. 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 the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (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
]
Darrel Schneider reassigned GEODE-8730:
---
Assignee: Bill Burcham
> 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: Test
> 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
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> ... 2 more
> * Execution Summary ***
> Script file: /geode/scripts/geode-starter-2.gfsh
> Command-1 : start locator --name=locator-maeve --connect=false
[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&focusedCommentId=17235580#comment-17235580
]
Geode Integration commented on GEODE-8730:
--
Seen in [AcceptanceTestOpenJDK8
#587|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK8/builds/587]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0502/test-results/acceptanceTest/1605801696/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0502/test-artifacts/1605801696/acceptancetestfiles-OpenJDK8-1.14.0-build.0502.tgz].
> 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: Test
> 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: j
[jira] [Created] (GEODE-8730) CI failure: DualServerSNIAcceptanceTest fails to start server because port is in use
Darrel Schneider created GEODE-8730:
---
Summary: 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: Test
Components: membership
Reporter: Darrel Schneider
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
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
... 2 more
* Execution Summary ***
Script file: /geode/scripts/geode-starter-2.gfsh
Command-1 : start locator --name=locator-maeve --connect=false
--redirect-output --hostname-for-clients=locator-maeve
--properties-file=/geode/config/gemfire.properties
--security-properties-file=/geode/config/gfsecurity.properties
--J=-Dgemfire.ssl-keystore=/geode/config/locator-maeve-keystore.jks
Status: PASSED
Command-2 : start server --name=server-dolores --group=group-dolores
--hostname-for-clients=server-dolores --locators=geode[10334]
--properties-file=/geode/config/
[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&focusedCommentId=17235606#comment-17235606
]
ASF GitHub Bot commented on GEODE-8664:
---
echobravopapa commented on pull request #5751:
URL: https://github.com/apache/geode/pull/5751#issuecomment-730521501
it's unclear what the actual issue this change is fixing... here is an
example of a recent bug we fixed caused by exceptions escaping...
https://issues.apache.org/jira/browse/GEODE-8697
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(InternalLoca
[jira] [Updated] (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:
Issue Type: Bug (was: Test)
> 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
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:794)
> ... 2 more
> * Execution Summary ***
> Script file: /geode/scripts/geode-starter-2.gfsh
> Command-1 : start locator --name=locator-maeve --connect=false
> --redire
[jira] [Created] (GEODE-8731) Remove inline functions from published headers
Matthew Reddington created GEODE-8731: - Summary: Remove inline functions from published headers Key: GEODE-8731 URL: https://issues.apache.org/jira/browse/GEODE-8731 Project: Geode Issue Type: Improvement Components: native client Reporter: Matthew Reddington Any inline functions found in cppcache/geode/include incur an ABI change and a version minor should any of that implementation need be changed. Nothing there should be inlined or defaulted. Move inlined methods into source files and bump the version minor. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235637#comment-17235637
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527099325
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
No, we can't reuse `timer.nanoTime()` since it will be different time at
the time of calculation.
I am still not convinced, but I will go ahead and make the change and let
you guys decide.
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.i
[jira] [Updated] (GEODE-8727) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated test[from_v1.2.0
[
https://issues.apache.org/jira/browse/GEODE-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jinmei Liao updated GEODE-8727:
---
Labels: caching-applications (was: )
> CI Failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> test[from_v1.2.0
>
>
> Key: GEODE-8727
> URL: https://issues.apache.org/jira/browse/GEODE-8727
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.14.0
>Reporter: Raymond Ingles
>Priority: Major
> Labels: caching-applications
>
> This test hung in an upgradeTest run. Stack traces show it interacting with
> a Locator and making progress over the 15 seconds between traces.
> CI webpage:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/589
> Artifacts are here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0500/test-artifacts/1605733271/upgradetestfiles-OpenJDK11-1.14.0-build.0500.tgz
> Here is the main test thread:
> {code:java}
> "Test worker" #27 prio=5 os_prio=0 cpu=4900.15ms elapsed=2902.12s
> tid=0x7fe70cbd4800 nid=0x1b runnable [0x7fe6d8894000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.9.1/Native
> Method)
> at
> java.net.SocketInputStream.socketRead(java.base@11.0.9.1/SocketInputStream.java:115)
> at
> java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:168)
> at
> java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:140)
> at
> java.io.BufferedInputStream.fill(java.base@11.0.9.1/BufferedInputStream.java:252)
> at
> java.io.BufferedInputStream.read(java.base@11.0.9.1/BufferedInputStream.java:271)
> - locked <0xf6487988> (a java.io.BufferedInputStream)
> at
> java.io.DataInputStream.readByte(java.base@11.0.9.1/DataInputStream.java:270)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.9.1/StreamRemoteCall.java:240)
> at
> sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.9.1/UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.9.1/RemoteObjectInvocationHandler.java:217)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.9.1/RemoteObjectInvocationHandler.java:162)
> at com.sun.proxy.$Proxy53.executeMethodOnObject(Unknown Source)
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase.rollServerToCurrent(LuceneSearchWithRollingUpgradeTestBase.java:347)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase.rollServerToCurrentCreateLuceneIndexAndCreateRegion(LuceneSearchWithRollingUpgradeTestBase.java:359)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:108)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.9.1/Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.9.1/NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.9.1/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.9.1/Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8732) Update Tomcat9 module to publish to Maven
Sarah Abbey created GEODE-8732: -- Summary: Update Tomcat9 module to publish to Maven Key: GEODE-8732 URL: https://issues.apache.org/jira/browse/GEODE-8732 Project: Geode Issue Type: Improvement Reporter: Sarah Abbey We need to publish geode-modules-tomcat9 to Maven so it can be utilized properly by users when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sarah Abbey updated GEODE-8732: --- Description: We need to publish geode-modules-tomcat9 to Maven so it can be utilized properly when consuming Geode via Maven. (was: We need to publish geode-modules-tomcat9 to Maven so it can be utilized properly by users when consuming Geode via Maven.) > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235653#comment-17235653 ] ASF GitHub Bot commented on GEODE-8732: --- sabbey37 opened a new pull request #5762: URL: https://github.com/apache/geode/pull/5762 We need to publish geode-modules-tomcat9 to Maven so it can be utilized properly when consuming Geode via Maven. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8732: -- Labels: pull-request-available (was: ) > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235654#comment-17235654 ] ASF GitHub Bot commented on GEODE-8700: --- gaussianrecurrence commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-730563953 > I am not sure I understand the motivation. Are you saying that you want to define the region in `cache.xml` and then later mutate it from the API? I am not sure how safe this would be given the general immutable nature of the region objects. What is the motivation to split the configuration this way. Our general recommendation is to use the API over the XML configuration anyway. The server is moving away from the XML configuration to cluster config and API config. The API provides the ability to provide an instantiated by the call instance of the resolver where the API must use "reflection" of sorts to new one up so context is disconnected with the application. Use case here is that we would like to have sort of a registry of partition resolvers, which we define in our application and in the cache XML file we specify which one of them we use for each partitioned region. That would be the ideal way of doing it. This way we only need to register all the partition resolvers we want to use. Also using a shared library is a no go as the application is basically a microservice, hence the less artifacts we have the better. I was not aware of the fact that the client was also moving away from declarative cache definition. If that's the case, there is no argument I can give you that justifies allowing to mutate the partition resolver. So being that the case, unless you think there is a possibility to see this implemented and accepted by the community, I guess I am closing the PR? Thanks for putting some time on this! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- 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&focusedCommentId=17235657#comment-17235657
]
ASF GitHub Bot commented on GEODE-8664:
---
kohlmu-pivotal commented on pull request #5751:
URL: https://github.com/apache/geode/pull/5751#issuecomment-730567727
@gaussianrecurrence Would it be possible for the you to reproduce the issue
that you are seeing (and trying to fix) and update the JIRA with this
information?
That will hopefully give the reviewers some context as to WHAT exactly you
are trying to fix.
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.ge
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235663#comment-17235663
]
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_r527124525
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
would something like this work:
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
> o
[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&focusedCommentId=17235666#comment-17235666
]
ASF GitHub Bot commented on GEODE-8664:
---
gaussianrecurrence commented on pull request #5751:
URL: https://github.com/apache/geode/pull/5751#issuecomment-730572491
Sorry @kohlmu-pivotal and @echobravopapa but I have been quite busy these
days.
The rationale behind this change is described already in the Jira
description, probably with not too much detail.
But quickly summarizing, while starting a locator if there is an exception
having to do with JGroups, the cause is not included in the top exception,
hence loosing the context on what's happening. Hopefully this clarifies the
intention of this fix.
Regarding about whether or not to leak the exception, I don't have an strong
point as Java is not my main language. But for what I can tell, there are these
exceptions which are internal and we wouldn't want these to be exposed, that's
why they are being wrapper as SystemConnectException and
GemFireConfigException. If that's the case I don't have any problem with that,
Still, unless I am missing something important here, what I believe is that
the exception cause should be there, otherwise troubleshooting these kind of
issues could be a real pain.
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.(C
[jira] [Updated] (GEODE-8664) JGroups exception is not propagated
[
https://issues.apache.org/jira/browse/GEODE-8664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Salazar de Torres updated GEODE-8664:
---
Description:
*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 org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:623)
at org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:217)
Caused by: java.lang.Exception: failed to open a port in range 53-53
at org.jgroups.protocols.UDP.createMulticastSocketWithBindPort(UDP.java:503)
at org.jgroups.protocols.UDP.createSockets(UDP.java:348)
at org.jgroups.protocols.UDP.start(UDP.java:266)
at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966)
at org.jgroups.JChannel.startStack(JChannel.java:889)
at org.jgroups.JChannel._preConnect(JChannel.java:553)
at org.jgroups.JChannel.connect(JChannel.java:288)
at org.jgroups.JChannel.connect(JChannel.java:279)
at
org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.start(JGroupsMessenger.java:393)
at
org.apache.geode.distributed.internal.membership.gms.Services.start(Services.java:203)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.start(GMSMembership.java:1853)
at
org.apache.geode.distributed.internal.DistributionImpl.start(DistributionImpl.java:171)
... 13 more{noformat}
For example in
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235670#comment-17235670
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527130659
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
I think will run the supplier and predicate one more time than the
previous iteration.
Using my previous example of 10 seconds timeout and 3 seconds sleep
(supplier and predicate execution time 0 and predicate always returns false), I
am supposed to throw the TimeoutException after sleeping for the last 1 second
, but your implementation will run supplier/predicate one more time and then
throw.
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(InternalDistributedSys
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235672#comment-17235672
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527130659
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
I think this will run the supplier and predicate one more time than the
previous implementation.
Using my previous example of 10 seconds timeout and 3 seconds sleep
(supplier and predicate execution time 0 and predicate always returns false), I
am supposed to throw the TimeoutException after sleeping for the last 1 second
, but your implementation will run supplier/predicate one more time and then
throw.
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(InternalDist
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235691#comment-17235691
]
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_r527144690
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
Agreed. With this approach we never return directly after a sleep.
(That's what @pivotal-jbarrett meant above when he said "No point in sleeping
if we are just going to fall through the while block immediately, we aren't
trying to delay the return but rather the execution of the code block") We
always return immediately after testing the predicate. It is different, but I
don't think it's wrong.
If we are bothering to sleep, it makes sense to give the predicate one last
try before returning. Otherwise why did we sleep?
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)
> a
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235695#comment-17235695
]
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_r527147213
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -32,18 +31,21 @@
interface Timer {
long nanoTime();
-void sleep(long sleepTime, TimeUnit sleepTimeUnit) throws
InterruptedException;
+void sleep(long sleepTimeInNano) throws InterruptedException;
}
- private static class SteadyTimer implements Timer {
+ static class SteadyTimer implements Timer {
@Override
public long nanoTime() {
return System.nanoTime();
}
@Override
-public void sleep(long sleepTime, TimeUnit sleepTimeUnit) throws
InterruptedException {
- Thread.sleep(MILLISECONDS.convert(sleepTime, sleepTimeUnit));
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ // avoid throwing IllegalArgumentException
+ if (sleepTimeInNano > 0) {
+Thread.sleep(NANOSECONDS.toMillis(sleepTimeInNano));
Review comment:
I recommend testing the condition _after_ the conversion to milliseconds
since e.g. `NANOSECONDS.toMillis(1) == 0`
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.UnknownHostE
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235696#comment-17235696
]
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_r527147993
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -82,7 +84,9 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
if (predicate.test(value)) {
return value;
} else {
-timer.sleep(interval, intervalUnit);
+long sleepTimeInNano =
+Math.min(NANOSECONDS.convert(interval, intervalUnit), until -
timer.nanoTime());
Review comment:
I recommend converting this outside the loop since it never changes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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.i
[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&focusedCommentId=17235698#comment-17235698
]
Owen Nichols commented on GEODE-2896:
-
I've pinned the pipeline back to the known-working Oct 14 image for now
> 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)
> or
[jira] [Created] (GEODE-8733) Local region holds onto data by reference
Patrick Johnsn created GEODE-8733:
-
Summary: Local region holds onto data by reference
Key: GEODE-8733
URL: https://issues.apache.org/jira/browse/GEODE-8733
Project: Geode
Issue Type: Improvement
Components: regions
Affects Versions: 1.13.0
Reporter: Patrick Johnsn
If the client region is configured as `CACHING_PROXY`, the data on the server
and the data in the local region can become out of sync because the local
region stores things by reference, for example, if you were to do:
{code:java}
list.add(1);
list.add(2);
list.add(3);
list.add(4);
map.put(1, "a");
map.put(2, "b");
map.put(3, "c");
map.put(4, "d");
Class1 obj = new Class1(1, list, map);
region.put(obj.id, obj);
map.clear();
list.clear();
map.put(12, "This shouldn't be here");
list.add(38);
System.out.println(region.get(1).toString());{code}
the values retrieved by region.get(1) would look like "Class1\{id=1,
someList=[38], someMap={12=This shouldn't be here}}" even though that update
was made AFTER the put.
If you queried the server, you'd get the expected values because you're going
directly to the server instead of the local region.
This issue was originally reported against Spring Data Geode but is
reproducible in plain Geode.
Original ticket for context: https://jira.spring.io/browse/DATAGEODE-388
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8733) Local region holds onto data by reference
[
https://issues.apache.org/jira/browse/GEODE-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Johnsn updated GEODE-8733:
--
Issue Type: Bug (was: Improvement)
> Local region holds onto data by reference
> -
>
> Key: GEODE-8733
> URL: https://issues.apache.org/jira/browse/GEODE-8733
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.13.0
>Reporter: Patrick Johnsn
>Priority: Major
>
> If the client region is configured as `CACHING_PROXY`, the data on the server
> and the data in the local region can become out of sync because the local
> region stores things by reference, for example, if you were to do:
>
> {code:java}
> list.add(1);
> list.add(2);
> list.add(3);
> list.add(4);
> map.put(1, "a");
> map.put(2, "b");
> map.put(3, "c");
> map.put(4, "d");
> Class1 obj = new Class1(1, list, map);
> region.put(obj.id, obj);
> map.clear();
> list.clear();
> map.put(12, "This shouldn't be here");
> list.add(38);
> System.out.println(region.get(1).toString());{code}
>
> the values retrieved by region.get(1) would look like "Class1\{id=1,
> someList=[38], someMap={12=This shouldn't be here}}" even though that update
> was made AFTER the put.
>
> If you queried the server, you'd get the expected values because you're going
> directly to the server instead of the local region.
>
> This issue was originally reported against Spring Data Geode but is
> reproducible in plain Geode.
> Original ticket for context: https://jira.spring.io/browse/DATAGEODE-388
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235722#comment-17235722
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527166017
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
I think I get your point, we already wasted some time, why don't we give
it another try? It all boils down to what you think is right or tolerable.
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
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235723#comment-17235723
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527166388
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -82,7 +84,9 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
if (predicate.test(value)) {
return value;
} else {
-timer.sleep(interval, intervalUnit);
+long sleepTimeInNano =
+Math.min(NANOSECONDS.convert(interval, intervalUnit), until -
timer.nanoTime());
Review comment:
no, it changes, only in the last iteration though.
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.bean
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235724#comment-17235724
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527166524
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -32,18 +31,21 @@
interface Timer {
long nanoTime();
-void sleep(long sleepTime, TimeUnit sleepTimeUnit) throws
InterruptedException;
+void sleep(long sleepTimeInNano) throws InterruptedException;
}
- private static class SteadyTimer implements Timer {
+ static class SteadyTimer implements Timer {
@Override
public long nanoTime() {
return System.nanoTime();
}
@Override
-public void sleep(long sleepTime, TimeUnit sleepTimeUnit) throws
InterruptedException {
- Thread.sleep(MILLISECONDS.convert(sleepTime, sleepTimeUnit));
+public void sleep(long sleepTimeInNano) throws InterruptedException {
+ // avoid throwing IllegalArgumentException
+ if (sleepTimeInNano > 0) {
+Thread.sleep(NANOSECONDS.toMillis(sleepTimeInNano));
Review comment:
good point.
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
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235730#comment-17235730 ] ASF GitHub Bot commented on GEODE-8700: --- pivotal-jbarrett commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-730614071 > Use case here is that we would like to have sort of a registry of partition resolvers, which we define in our application and in the cache XML file we specify which one of them we use for each partitioned region. That would be the ideal way of doing it. This way we only need to register all the partition resolvers we want to use. > Also using a shared library is a no go as the application is basically a microservice, hence the less artifacts we have the better. I get wanting to declare them in the XML so again I don't get why need this PR to make the region resolver mutable. If the resolver is defined in the XML then it should work as designed. I think what your real issue is that if you have the classes defined in your application how do you declare them in the XML if the XML config expects a shared library name and symbol name for factory. That is something we could easily fix. How about allowing the library name to be optional. If there is no library name then the symbol lookup would happen in the current application space. I think that is possible. 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 the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235737#comment-17235737
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527185523
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
you know if you change your implementation a little bit, instead of `if
(sleepNanos > 0)` we change it to `if(sleepNanos == intervalNanos)`, I think
this would be best.
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
you know if we change your implementation a little bit, instead of `if
(sleepNanos > 0)` we change it to `if(
[jira] [Commented] (GEODE-8318) Shutdown hang and abort
[ https://issues.apache.org/jira/browse/GEODE-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235739#comment-17235739 ] ASF GitHub Bot commented on GEODE-8318: --- lgtm-com[bot] commented on pull request #695: URL: https://github.com/apache/geode-native/pull/695#issuecomment-730630356 This pull request **fixes 2 alerts** when merging f3b2994e1bb4c7a30437f522c301f2a8e192620b into 0f4a3be938d466c1b559d4129cb95b372d47e68a - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-e7fe42462150170e4e2c452162658bd02e2bf8f6) **fixed alerts:** * 2 for Comparison result is always the same This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Shutdown hang and abort > --- > > Key: GEODE-8318 > URL: https://issues.apache.org/jira/browse/GEODE-8318 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Matthew Reddington >Assignee: Alberto Gomez >Priority: Major > Labels: pull-request-available > > Switching from Ace to Boost.Asio has revealed threading issues related to > shutdown. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8623) Timing between DNS and Geode startup can result in permanent unknown host exceptions.
[
https://issues.apache.org/jira/browse/GEODE-8623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235744#comment-17235744
]
ASF GitHub Bot commented on GEODE-8623:
---
jinmeiliao commented on a change in pull request #5743:
URL: https://github.com/apache/geode/pull/5743#discussion_r527198561
##
File path: geode-common/src/main/java/org/apache/geode/internal/Retry.java
##
@@ -47,45 +47,44 @@ public void sleep(long sleepTime, TimeUnit sleepTimeUnit)
throws InterruptedExce
}
}
- private static final SteadyClock steadyClock = new SteadyClock();
+ 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 timeUnit to retry for
+ * @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,
- long interval,
- TimeUnit timeUnit,
+ public static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate) throws TimeoutException, InterruptedException {
-return tryFor(timeout, interval, timeUnit, supplier, predicate,
steadyClock);
+return tryFor(timeout, timeoutUnit, interval, intervalUnit, supplier,
predicate, steadyClock);
}
@VisibleForTesting
- static T tryFor(long timeout,
- long interval,
- TimeUnit timeUnit,
+ static T tryFor(long timeout, TimeUnit timeoutUnit,
+ long interval, TimeUnit intervalUnit,
Supplier supplier,
Predicate predicate,
- Clock clock) throws TimeoutException, InterruptedException {
-long until = clock.nanoTime() + NANOSECONDS.convert(timeout, timeUnit);
+ Timer timer) throws TimeoutException, InterruptedException {
+long until = timer.nanoTime() + NANOSECONDS.convert(timeout, timeoutUnit);
T value;
do {
value = supplier.get();
if (predicate.test(value)) {
return value;
} else {
-clock.sleep(interval, timeUnit);
+timer.sleep(interval, intervalUnit);
Review comment:
Ok, I think my last commit combines the good points of both
implementation. Thanks for all the points and nudges.
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
[jira] [Commented] (GEODE-8521) Add P2P message reader threads to thread monitoring
[ https://issues.apache.org/jira/browse/GEODE-8521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235746#comment-17235746 ] ASF GitHub Bot commented on GEODE-8521: --- dschneider-pivotal opened a new pull request #5763: URL: https://github.com/apache/geode/pull/5763 Each p2p reader thread now creates a single instance of AbstractExecutor and registers it with the ThreadsMonitoring instance while it is "dispatching" the message. It will not be monitored while it is waiting on the socket to read a message. So this will only report stuck p2p readers that are stuck dispatch which for inline processing includes processing the message and reading the direct ack. 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 > 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-8693) C++ native client Function.execute() with onServers does not throw exception if one of the servers goes down while executing the function.
[ https://issues.apache.org/jira/browse/GEODE-8693?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235765#comment-17235765 ] ASF GitHub Bot commented on GEODE-8693: --- codecov-io edited a comment on pull request #690: URL: https://github.com/apache/geode-native/pull/690#issuecomment-728320149 # [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=h1) Report > Merging [#690](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=desc) (07eeb9f) into [develop](https://codecov.io/gh/apache/geode-native/commit/5c7d47d34c2b8a53874ec6f53e66c2290fd0427c?el=desc) (5c7d47d) will **decrease** coverage by `0.05%`. > The diff coverage is `50.00%`. [](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) ```diff @@ Coverage Diff @@ ## develop #690 +/- ## === - Coverage74.12% 74.07% -0.06% === Files 644 644 Lines5118751184 -3 === - Hits 3794237913 -29 - Misses 1324513271 +26 ``` | [Impacted Files](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=tree) | Coverage Δ | | |---|---|---| | [cppcache/src/CqQueryImpl.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0NxUXVlcnlJbXBsLmNwcA==) | `56.37% <0.00%> (ø)` | | | [cppcache/src/ExecutionImpl.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL0V4ZWN1dGlvbkltcGwuY3Bw) | `69.92% <28.57%> (+1.84%)` | :arrow_up: | | [cppcache/src/ThinClientPoolDM.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRQb29sRE0uY3Bw) | `77.36% <100.00%> (+0.87%)` | :arrow_up: | | [cppcache/src/ReadWriteLock.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1JlYWRXcml0ZUxvY2suY3Bw) | `62.50% <0.00%> (-37.50%)` | :arrow_down: | | [...tion-test/testThinClientRemoteQueryFailoverPdx.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvaW50ZWdyYXRpb24tdGVzdC90ZXN0VGhpbkNsaWVudFJlbW90ZVF1ZXJ5RmFpbG92ZXJQZHguY3Bw) | `85.48% <0.00%> (-4.04%)` | :arrow_down: | | [cppcache/src/TXCommitMessage.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RYQ29tbWl0TWVzc2FnZS5jcHA=) | `74.50% <0.00%> (-1.97%)` | :arrow_down: | | [cppcache/src/TcrEndpoint.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RjckVuZHBvaW50LmNwcA==) | `55.11% <0.00%> (-1.55%)` | :arrow_down: | | [cppcache/src/ThinClientLocatorHelper.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1RoaW5DbGllbnRMb2NhdG9ySGVscGVyLmNwcA==) | `85.31% <0.00%> (-1.20%)` | :arrow_down: | | [...tegration-test/testThinClientRemoteRegionQuery.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvaW50ZWdyYXRpb24tdGVzdC90ZXN0VGhpbkNsaWVudFJlbW90ZVJlZ2lvblF1ZXJ5LmNwcA==) | `82.33% <0.00%> (-1.13%)` | :arrow_down: | | [cppcache/src/RemoteQuery.cpp](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree#diff-Y3BwY2FjaGUvc3JjL1JlbW90ZVF1ZXJ5LmNwcA==) | `75.53% <0.00%> (-1.07%)` | :arrow_down: | | ... and [8 more](https://codecov.io/gh/apache/geode-native/pull/690/diff?src=pr&el=tree-more) | | -- [Continue to review full report at Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=continue). > **Legend** - [Click here to learn more](https://docs.codecov.io/docs/codecov-delta) > `Δ = absolute (impact)`, `ø = not affected`, `? = missing data` > Powered by [Codecov](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=footer). Last update [5c7d47d...07eeb9f](https://codecov.io/gh/apache/geode-native/pull/690?src=pr&el=lastupdated). Read the [comment docs](https://docs.codecov.io/docs/pull-request-comments). 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 > C++ native client Function.execute() with onServers does not throw exception > if one of the servers goes down while executing the function. > --
[jira] [Commented] (GEODE-8667) Duplicate online Oplog compaction after offline Oplog compaction
[ https://issues.apache.org/jira/browse/GEODE-8667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235780#comment-17235780 ] ASF GitHub Bot commented on GEODE-8667: --- jchen21 commented on pull request #5689: URL: https://github.com/apache/geode/pull/5689#issuecomment-730682983 > add unit test coverage of needsCompaction to OplogTest. > > It seems like the only change you made was to say we don't need to compact if an Oplog has a totalCount == 0. I think totalCount == 0 means that the oplog is empty. This seems like something we should compact. Do you understand why offline compaction gave us an empty oplog? I'm concerned this change might cause us not to remove empty oplogs. Or maybe we say it has no need to compact but still do a check and remove it for being empty somewhere else? I have added a unit test in `OplogTest`. `totalCount` == 0 does not necessarily mean the oplog is empty. You remind me of the case of an empty oplog. There is another field `totalLiveCount` to check. What I see in the persistent recovery immediately after an offline compaction is, the offline compacted oplog is non-empty. During the recovery, `totalCount` is `0`. However, `totalLiveCount` has the actual number of live entries in the oplog. Therefore I add one more condition to check `totalLiveCount`. If `totalCount` == 0 and `totalLiveCount` > 0, such as the case of recovery after offline compaction, we don't need compaction again. Are there any other cases that need compaction, even though `totalCount` == 0 and `totalLiveCount` > 0? If `totalCount` == 0 and `totalLiveCount` <= 0, then the oplog is empty, which needs compaction. Please correct me if I am wrong. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Duplicate online Oplog compaction after offline Oplog compaction > > > Key: GEODE-8667 > URL: https://issues.apache.org/jira/browse/GEODE-8667 > Project: Geode > Issue Type: Bug >Reporter: Jianxia Chen >Assignee: Jianxia Chen >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > > Use `compact offline-disk-store` command to compact the Oplogs offline. > Then restart the servers. > The logs show OplogCompactor thread is compacting Oplogs again when > restarting the servers, even though the Oplogs were just compacted offline. > For example: > ``` > [info 2020/10/27 16:32:22.534 PDT tid=0x35] Recovered > values for disk store DEFAULT with unique id > 76393d3c-dd10-4b89-b655-821d37631774 > [info 2020/10/27 16:32:22.535 PDT > tid=0x35] OplogCompactor for DEFAULT compaction oplog id(s): oplog#2 > [info 2020/10/27 16:32:22.537 PDT > tid=0x35] compaction did 2 creates and updates in 2 ms > [info 2020/10/27 16:32:22.537 PDT tid=0x36] Deleted > oplog#2 crf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 krf for disk store DEFAULT. > [info 2020/10/27 16:32:22.538 PDT tid=0x36] Deleted > oplog#2 drf for disk store DEFAULT. > ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8724) Fix compilation using geode-native docker image
[ https://issues.apache.org/jira/browse/GEODE-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235790#comment-17235790 ] ASF GitHub Bot commented on GEODE-8724: --- onichols-pivotal commented on pull request #696: URL: https://github.com/apache/geode-native/pull/696#issuecomment-730702705 @pivotal-jbarrett how was your image different from the corrected image that Release Manager @dickcav pushed? Did you push to both `1.13.1` and `latest` tags? On which branch(es) are the Dockerfile changes commited that you pushed? 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 > Fix compilation using geode-native docker image > --- > > Key: GEODE-8724 > URL: https://issues.apache.org/jira/browse/GEODE-8724 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > As geode-native was re-built and re-uploaded, it's now using the latest > version of ubuntu, which is 20.04 as of some months. > Thing is docker builds started to fail after uploading the new docker image. > This task is intended to look into the issue and propose one/several > solutions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8724) Fix compilation using geode-native docker image
[ https://issues.apache.org/jira/browse/GEODE-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235791#comment-17235791 ] ASF GitHub Bot commented on GEODE-8724: --- dickcav commented on pull request #696: URL: https://github.com/apache/geode-native/pull/696#issuecomment-730704325 Yesterday afternoon is when we did what @gaussianrecurrence requested and merged the change, rebuilt docket and pushed but maybe that wasn't apparent that happened? 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 > Fix compilation using geode-native docker image > --- > > Key: GEODE-8724 > URL: https://issues.apache.org/jira/browse/GEODE-8724 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > As geode-native was re-built and re-uploaded, it's now using the latest > version of ubuntu, which is 20.04 as of some months. > Thing is docker builds started to fail after uploading the new docker image. > This task is intended to look into the issue and propose one/several > solutions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8724) Fix compilation using geode-native docker image
[ https://issues.apache.org/jira/browse/GEODE-8724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235795#comment-17235795 ] ASF GitHub Bot commented on GEODE-8724: --- pivotal-jbarrett commented on pull request #696: URL: https://github.com/apache/geode-native/pull/696#issuecomment-730707525 When I looked at hub.docker the most recent image pushed were older than the commit. I see the new images are only a few hours old. All should be fine now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix compilation using geode-native docker image > --- > > Key: GEODE-8724 > URL: https://issues.apache.org/jira/browse/GEODE-8724 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.0, 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > As geode-native was re-built and re-uploaded, it's now using the latest > version of ubuntu, which is 20.04 as of some months. > Thing is docker builds started to fail after uploading the new docker image. > This task is intended to look into the issue and propose one/several > solutions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (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:all-tabpanel ] Donal Evans reassigned GEODE-8734: -- Assignee: 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 > > 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] [Created] (GEODE-8734) LinuxProcFsStatistics.getNetStatStats() may incorrectly parse /proc/net/netstat file
Donal Evans created GEODE-8734: -- Summary: 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.13.1, 1.12.1, 1.14.0 Reporter: Donal Evans 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] [Updated] (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:all-tabpanel ] ASF GitHub Bot updated GEODE-8734: -- Labels: pull-request-available (was: ) > 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&focusedCommentId=17235797#comment-17235797 ] ASF GitHub Bot commented on GEODE-8734: --- DonalEvans opened a new pull request #5764: URL: https://github.com/apache/geode/pull/5764 Authored-by: Donal Evans Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [x] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [x] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [x] Is your initial contribution a single, squashed commit? - [x] Does `gradlew build` run cleanly? - [x] Have you written or updated unit tests to verify your changes? - [N/A] 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 > > 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] [Reopened] (GEODE-8713) Geode-Native .NET user guide: API reference links point to C++ API
[ https://issues.apache.org/jira/browse/GEODE-8713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reopened GEODE-8713: Reopening: This solution passed all local tests, but fails when posted to the Geode website. Reason: The website does not honor the Ruby 'redirects.rb' file, which is required for this solution. Alternative: Hard-code the API links in the client cache references (5 occurrences in each book) to the same address used in the 'about' page of the manual. > Geode-Native .NET user guide: API reference links point to C++ API > -- > > Key: GEODE-8713 > URL: https://issues.apache.org/jira/browse/GEODE-8713 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.13.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > The "Client Cache XML Reference" section in the .NET user guide contains > links to "API Class Reference" that all point to the C++ API ref. These > should point to the .NET API ref. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235813#comment-17235813 ] ASF GitHub Bot commented on GEODE-8700: --- gaussianrecurrence commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-730766998 > > Use case here is that we would like to have sort of a registry of partition resolvers, which we define in our application and in the cache XML file we specify which one of them we use for each partitioned region. That would be the ideal way of doing it. This way we only need to register all the partition resolvers we want to use. > > Also using a shared library is a no go as the application is basically a microservice, hence the less artifacts we have the better. > > I get wanting to declare them in the XML so again I don't get why need this PR to make the region resolver mutable. If the resolver is defined in the XML then it should work as designed. > > I think what your real issue is that if you have the classes defined in your application how do you declare them in the XML if the XML config expects a shared library name and symbol name for factory. That is something we could easily fix. How about allowing the library name to be optional. If there is no library name then the symbol lookup would happen in the current application space. I think that is possible. You are right > > Use case here is that we would like to have sort of a registry of partition resolvers, which we define in our application and in the cache XML file we specify which one of them we use for each partitioned region. That would be the ideal way of doing it. This way we only need to register all the partition resolvers we want to use. > > Also using a shared library is a no go as the application is basically a microservice, hence the less artifacts we have the better. > > I get wanting to declare them in the XML so again I don't get why need this PR to make the region resolver mutable. If the resolver is defined in the XML then it should work as designed. > > I think what your real issue is that if you have the classes defined in your application how do you declare them in the XML if the XML config expects a shared library name and symbol name for factory. That is something we could easily fix. How about allowing the library name to be optional. If there is no library name then the symbol lookup would happen in the current application space. I think that is possible. Regarding mutating the partition resolver, we are on the same point, it's not ideal, and I will abandon this approach. Regarding looking into the application space, that's a great idea, which I've already tested and it's working. So I will push a change with 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 > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- 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&focusedCommentId=17235814#comment-17235814 ] ASF subversion and git services commented on GEODE-8661: Commit ed4644f93043b6e460b45387cbb6fd6ad43ac516 in geode's branch refs/heads/support/1.12 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.14.0 > > > 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-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235815#comment-17235815 ] ASF GitHub Bot commented on GEODE-8700: --- pivotal-jbarrett commented on pull request #691: URL: https://github.com/apache/geode-native/pull/691#issuecomment-730772790 Closing this PR based on the conversation above. Looking forward to a PR that fixes the factory lookup logic. 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 the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235816#comment-17235816 ] ASF GitHub Bot commented on GEODE-8700: --- pivotal-jbarrett closed pull request #691: URL: https://github.com/apache/geode-native/pull/691 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 the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8700) Add the ability to change the partition resolver
[ https://issues.apache.org/jira/browse/GEODE-8700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-8700. Resolution: Abandoned As discussed in the linked PR, will solve the issue in a much more generic way, which does not involves having to mutate the partition resolver. > Add the ability to change the partition resolver > > > Key: GEODE-8700 > URL: https://issues.apache.org/jira/browse/GEODE-8700 > Project: Geode > Issue Type: New Feature > Components: native client >Affects Versions: 1.13.0 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *AS A* native client contributor > *I WANT* to be able to mutate partition resolver > *SO THAT* I don't need to create a shared library to specify one. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (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:all-tabpanel ] Owen Nichols updated GEODE-8661: Fix Version/s: 1.13.2 1.12.1 > 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] [Created] (GEODE-8735) Enable factory lookup logic to look for symbols in the application
Mario Salazar de Torres created GEODE-8735:
--
Summary: Enable factory lookup logic to look for symbols in the
application
Key: GEODE-8735
URL: https://issues.apache.org/jira/browse/GEODE-8735
Project: Geode
Issue Type: Improvement
Components: native client
Affects Versions: 1.13.1
Reporter: Mario Salazar de Torres
*AS A* native client contributor
*I WANT* to be able to specify factory names within the application space
*SO THAT* the user does not need to create a separate shared library to load
several items like partition resolvers, cache loaders, cache writers, partition
resolvers...
*Additional information*
The rationale for this change is that if the user wants to declaratively
specify a partition resolver, right now the only way is by creating the shared
library.
So the idea would be to change the current factory implementation, so library
name is an optional field, and whenever "library-name" is not specified, the
client will look for symbols within the application instead.
*For example:*
Using this region definition:
{code:xml}
{code}
And within the application defining this function:
{code:cpp}
APPLICATION_EXPORT PartitionResolver* createPartitionResolver()
{
return new StringPrefixPartitionResolver{};
}
{code}
You could declaratively create a region which uses the
StringPrefixPartitionResolver.
*IMPORTANT.* Take into account that documentation should be updated in order to
indicate that library-name will become an optional field and what it means
whenever it's not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8735) Enable factory lookup logic to look for symbols in the application
[
https://issues.apache.org/jira/browse/GEODE-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235836#comment-17235836
]
ASF GitHub Bot commented on GEODE-8735:
---
gaussianrecurrence opened a new pull request #700:
URL: https://github.com/apache/geode-native/pull/700
- In order to allow that factory logic looks into the application space
for symbols, `library-name` field has been made optional.
- This removes the need to create shared library for in order to define
custom factories like cache loaders, cache writers, cache listeners,
partition resolvers or persistance managers whenever the cache is
instantiated declaratively.
- Whenever library-name is not specified a handle to the executable is
obtained.
- Take into account that for OS like Linux, Mac... in addition to exporting
the symbols in the application, you would need to specify `-rdynamic`
option while compiling.
- Documentation has been updated.
---
**NOTE**. Take a look into the Jira issue for additional context.
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
> Enable factory lookup logic to look for symbols in the application
> --
>
> Key: GEODE-8735
> URL: https://issues.apache.org/jira/browse/GEODE-8735
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.13.1
>Reporter: Mario Salazar de Torres
>Priority: Major
>
> *AS A* native client contributor
> *I WANT* to be able to specify factory names within the application space
> *SO THAT* the user does not need to create a separate shared library to load
> several items like partition resolvers, cache loaders, cache writers,
> partition resolvers...
>
> *Additional information*
> The rationale for this change is that if the user wants to declaratively
> specify a partition resolver, right now the only way is by creating the
> shared library.
> So the idea would be to change the current factory implementation, so library
> name is an optional field, and whenever "library-name" is not specified, the
> client will look for symbols within the application instead.
> *For example:*
> Using this region definition:
> {code:xml}
>
>pool-name="partitioned-pool">
>
>
>
> {code}
> And within the application defining this function:
> {code:cpp}
> APPLICATION_EXPORT PartitionResolver* createPartitionResolver()
> {
> return new StringPrefixPartitionResolver{};
> }
> {code}
> You could declaratively create a region which uses the
> StringPrefixPartitionResolver.
> *IMPORTANT.* Take into account that documentation should be updated in order
> to indicate that library-name will become an optional field and what it means
> whenever it's not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8735) Enable factory lookup logic to look for symbols in the application
[
https://issues.apache.org/jira/browse/GEODE-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-8735:
--
Labels: pull-request-available (was: )
> Enable factory lookup logic to look for symbols in the application
> --
>
> Key: GEODE-8735
> URL: https://issues.apache.org/jira/browse/GEODE-8735
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.13.1
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS A* native client contributor
> *I WANT* to be able to specify factory names within the application space
> *SO THAT* the user does not need to create a separate shared library to load
> several items like partition resolvers, cache loaders, cache writers,
> partition resolvers...
>
> *Additional information*
> The rationale for this change is that if the user wants to declaratively
> specify a partition resolver, right now the only way is by creating the
> shared library.
> So the idea would be to change the current factory implementation, so library
> name is an optional field, and whenever "library-name" is not specified, the
> client will look for symbols within the application instead.
> *For example:*
> Using this region definition:
> {code:xml}
>
>pool-name="partitioned-pool">
>
>
>
> {code}
> And within the application defining this function:
> {code:cpp}
> APPLICATION_EXPORT PartitionResolver* createPartitionResolver()
> {
> return new StringPrefixPartitionResolver{};
> }
> {code}
> You could declaratively create a region which uses the
> StringPrefixPartitionResolver.
> *IMPORTANT.* Take into account that documentation should be updated in order
> to indicate that library-name will become an optional field and what it means
> whenever it's not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235844#comment-17235844 ] ASF GitHub Bot commented on GEODE-8732: --- kohlmu-pivotal commented on pull request #5762: URL: https://github.com/apache/geode/pull/5762#issuecomment-730804827 Just for interest sake, what is the use case that we now have to publish these extensions, which previously we've never had to publish before? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8735) Enable factory lookup logic to look for symbols in the application
[
https://issues.apache.org/jira/browse/GEODE-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235860#comment-17235860
]
ASF GitHub Bot commented on GEODE-8735:
---
pivotal-jbarrett commented on a change in pull request #700:
URL: https://github.com/apache/geode-native/pull/700#discussion_r527365312
##
File path: cppcache/src/Utils.cpp
##
@@ -173,20 +174,22 @@ const boost::dll::shared_library& getSharedLibrary(
const auto& find = sharedLibraries.find(libraryName);
if (find == sharedLibraries.end()) {
+auto path = libraryName.empty() ? boost::dll::program_location()
Review comment:
Great timing for me merging the boost::dll changes the other day. This
change looks pretty straight forward!
##
File path: cppcache/src/Utils.cpp
##
@@ -173,20 +174,22 @@ const boost::dll::shared_library& getSharedLibrary(
const auto& find = sharedLibraries.find(libraryName);
if (find == sharedLibraries.end()) {
+auto path = libraryName.empty() ? boost::dll::program_location()
+: boost::dll::fs::path{libraryName};
try {
return *sharedLibraries
.emplace(
libraryName,
std::make_shared(
- libraryName,
+ path,
boost::dll::load_mode::rtld_global |
boost::dll::load_mode::rtld_lazy |
boost::dll::load_mode::append_decorations |
boost::dll::load_mode::search_system_folders))
.first->second;
} catch (const boost::dll::fs::system_error& e) {
- throw IllegalArgumentException("cannot open library: " + libraryName +
- ": reason: " + e.what());
+ throw IllegalArgumentException("cannot open library: \"" + libraryName +
Review comment:
I wonder if path makes more sense here now? Can the `shared_library`
construction fail ever in the case of `program_location`?
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
> Enable factory lookup logic to look for symbols in the application
> --
>
> Key: GEODE-8735
> URL: https://issues.apache.org/jira/browse/GEODE-8735
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.13.1
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS A* native client contributor
> *I WANT* to be able to specify factory names within the application space
> *SO THAT* the user does not need to create a separate shared library to load
> several items like partition resolvers, cache loaders, cache writers,
> partition resolvers...
>
> *Additional information*
> The rationale for this change is that if the user wants to declaratively
> specify a partition resolver, right now the only way is by creating the
> shared library.
> So the idea would be to change the current factory implementation, so library
> name is an optional field, and whenever "library-name" is not specified, the
> client will look for symbols within the application instead.
> *For example:*
> Using this region definition:
> {code:xml}
>
>pool-name="partitioned-pool">
>
>
>
> {code}
> And within the application defining this function:
> {code:cpp}
> APPLICATION_EXPORT PartitionResolver* createPartitionResolver()
> {
> return new StringPrefixPartitionResolver{};
> }
> {code}
> You could declaratively create a region which uses the
> StringPrefixPartitionResolver.
> *IMPORTANT.* Take into account that documentation should be updated in order
> to indicate that library-name will become an optional field and what it means
> whenever it's not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8736) maintain native and docs Geode version as part of release scripts
Owen Nichols created GEODE-8736: --- Summary: 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 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] [Updated] (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 ] ASF GitHub Bot updated GEODE-8736: -- Labels: pull-request-available (was: ) > 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&focusedCommentId=17235863#comment-17235863 ] ASF GitHub Bot commented on GEODE-8736: --- onichols-pivotal opened a new pull request #5765: URL: https://github.com/apache/geode/pull/5765 travis, lgtm, and Dockerfile in native (support branch and develop) are now updated when a new version of Geode is released product_version for Geode docs are now updated when a new version of Geode is released 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 > > 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-8732) Update Tomcat9 module to publish to Maven
[ https://issues.apache.org/jira/browse/GEODE-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235866#comment-17235866 ] ASF GitHub Bot commented on GEODE-8732: --- pivotal-jbarrett commented on pull request #5762: URL: https://github.com/apache/geode/pull/5762#issuecomment-730821726 > Just for interest sake, what is the use case that we now have to publish these extensions, which previously we've never had to publish before? Anyone downstream that wanted to include the Tomcat session manager into their build process had to do so outside of the Maven repo coordinates. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Update Tomcat9 module to publish to Maven > - > > Key: GEODE-8732 > URL: https://issues.apache.org/jira/browse/GEODE-8732 > Project: Geode > Issue Type: Improvement >Reporter: Sarah Abbey >Priority: Major > Labels: pull-request-available > > We need to publish geode-modules-tomcat9 to Maven so it can be utilized > properly when consuming Geode via Maven. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8735) Enable factory lookup logic to look for symbols in the application
[
https://issues.apache.org/jira/browse/GEODE-8735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17235867#comment-17235867
]
ASF GitHub Bot commented on GEODE-8735:
---
pivotal-jbarrett commented on pull request #700:
URL: https://github.com/apache/geode-native/pull/700#issuecomment-730822328
> * Take into account that for OS like Linux, Mac... in addition to exporting
> the symbols in the application, you would need to specify `-rdynamic`
> option while compiling.
This might make great example with corresponding CMake configuration.
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
> Enable factory lookup logic to look for symbols in the application
> --
>
> Key: GEODE-8735
> URL: https://issues.apache.org/jira/browse/GEODE-8735
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Affects Versions: 1.13.1
>Reporter: Mario Salazar de Torres
>Priority: Major
> Labels: pull-request-available
>
> *AS A* native client contributor
> *I WANT* to be able to specify factory names within the application space
> *SO THAT* the user does not need to create a separate shared library to load
> several items like partition resolvers, cache loaders, cache writers,
> partition resolvers...
>
> *Additional information*
> The rationale for this change is that if the user wants to declaratively
> specify a partition resolver, right now the only way is by creating the
> shared library.
> So the idea would be to change the current factory implementation, so library
> name is an optional field, and whenever "library-name" is not specified, the
> client will look for symbols within the application instead.
> *For example:*
> Using this region definition:
> {code:xml}
>
>pool-name="partitioned-pool">
>
>
>
> {code}
> And within the application defining this function:
> {code:cpp}
> APPLICATION_EXPORT PartitionResolver* createPartitionResolver()
> {
> return new StringPrefixPartitionResolver{};
> }
> {code}
> You could declaratively create a region which uses the
> StringPrefixPartitionResolver.
> *IMPORTANT.* Take into account that documentation should be updated in order
> to indicate that library-name will become an optional field and what it means
> whenever it's not present.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8737) Create new geode example for rest api
Ashish Choudhary created GEODE-8737: --- Summary: Create new geode example for rest api Key: GEODE-8737 URL: https://issues.apache.org/jira/browse/GEODE-8737 Project: Geode Issue Type: New Feature Components: examples Reporter: Ashish Choudhary Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8737) Create new geode example for about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Choudhary reassigned GEODE-8737: --- Assignee: Ashish Choudhary > Create new geode example for about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Assignee: Ashish Choudhary >Priority: Major > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8737) Create new geode example for about rest api
[ https://issues.apache.org/jira/browse/GEODE-8737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashish Choudhary updated GEODE-8737: Summary: Create new geode example for about rest api (was: Create new geode example for rest api) > Create new geode example for about rest api > --- > > Key: GEODE-8737 > URL: https://issues.apache.org/jira/browse/GEODE-8737 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ashish Choudhary >Priority: Major > > Create new example that demonstrate use of geode rest api. -- This message was sent by Atlassian Jira (v8.3.4#803005)
