[jira] [Resolved] (GEODE-9092) Package splitting geode-common
[ https://issues.apache.org/jira/browse/GEODE-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9092. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-common > -- > > Key: GEODE-9092 > URL: https://issues.apache.org/jira/browse/GEODE-9092 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9092) Package splitting geode-common
[ https://issues.apache.org/jira/browse/GEODE-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335139#comment-17335139 ] ASF subversion and git services commented on GEODE-9092: Commit f8793f8f51838051b9ed2927f6259dbae48f6224 in geode's branch refs/heads/develop from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8793f8 ] GEODE-9092: Resolve package splitting geode-common (#6216) Co-authored-by: Udo Kohlmeyer Co-authored-by: Patrick Johnson > Package splitting geode-common > -- > > Key: GEODE-9092 > URL: https://issues.apache.org/jira/browse/GEODE-9092 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9093) Package splitting geode-connectors
[ https://issues.apache.org/jira/browse/GEODE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9093. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-connectors > -- > > Key: GEODE-9093 > URL: https://issues.apache.org/jira/browse/GEODE-9093 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9093) Package splitting geode-connectors
[ https://issues.apache.org/jira/browse/GEODE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335138#comment-17335138 ] ASF subversion and git services commented on GEODE-9093: Commit 94104d2ebf5a9a39a7d2babb975ffb9fe4a640a4 in geode's branch refs/heads/develop from Udo Kohlmeyer [ https://gitbox.apache.org/repos/asf?p=geode.git;h=94104d2 ] GEODE-9093 - Resolve package splitting for geode-connectors (#6217) Co-authored-by: Udo Kohlmeyer Co-authored-by: Patrick Johnson > Package splitting geode-connectors > -- > > Key: GEODE-9093 > URL: https://issues.apache.org/jira/browse/GEODE-9093 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9092) Package splitting geode-common
[ https://issues.apache.org/jira/browse/GEODE-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9092: -- Labels: pull-request-available (was: ) > Package splitting geode-common > -- > > Key: GEODE-9092 > URL: https://issues.apache.org/jira/browse/GEODE-9092 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335132#comment-17335132
]
ASF subversion and git services commented on GEODE-9193:
Commit ac6a96072faa313814ad77f39e4511f472cfd62d in geode-native's branch
refs/heads/develop from Blake Bender
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=ac6a960 ]
GEODE-9193: Use local object variable for PING messages. (#792)
Just declare a local variable, rather than attempt to cache the message
- Make DataOutput param to ping message ctor a smart pointer
- Remove unused 'decodeAll' param from ping message ctor
- Remove some unused local vars in test code
> PING message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335133#comment-17335133
]
ASF GitHub Bot commented on GEODE-9193:
---
pdxcodemonkey merged pull request #792:
URL: https://github.com/apache/geode-native/pull/792
--
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 message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335073#comment-17335073
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#175|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/175]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0176/test-results/distributedTest/1619652866/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0176/test-artifacts/1619652866/distributedtestfiles-OpenJDK8-1.15.0-build.0176.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9161) No gradle 7 deprecation warnings [PERMANENT]
[ https://issues.apache.org/jira/browse/GEODE-9161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335072#comment-17335072 ] ASF subversion and git services commented on GEODE-9161: Commit f6fee953dcc99d8fff605f1a30f7d5523dbcfec4 in geode's branch refs/heads/develop from M. Oleske [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f6fee95 ] GEODE-9161: Use not deperacted property in gradle build (#6388) - remember friends that if you switch from string to property, you need a `.get()` Authored-by: M. Oleske > No gradle 7 deprecation warnings [PERMANENT] > > > Key: GEODE-9161 > URL: https://issues.apache.org/jira/browse/GEODE-9161 > Project: Geode > Issue Type: Improvement > Components: build >Reporter: Michael Oleske >Priority: Major > Labels: pull-request-available > > Why this is important: At some point this project will update to gradle 7, > and it is better to stay on top of things then behind > Given I have cloned the geode repository > When I run ./gradlew build --warning-mode=all > Then I see no output about "This will fail in gradle 7.0" or "This is > scheduled to be removed in Gradle 7.0" > Notes: > Not all warnings appear at first, you'll likely have to run with several > times as you clean up > There are some gradle 8.0 warnings. If you happen to clean those up nice! > Otherwise ok to skip for now. > There's some oddities with properties being hardcoded in other places to > their deprecated name which probably requires real work. > The following types of errors are in the project > The testRuntime configuration has been deprecated for dependency declaration. > This will fail with an error in Gradle 7.0. Please use the testRuntimeOnly > configuration instead. Consult the upgrading guide for further information: > https://docs.gradle.org/6.8.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations > The compile configuration has been deprecated for dependency declaration. > This will fail with an error in Gradle 7.0. Please use the implementation or > api configuration instead. Consult the upgrading guide for further > information: > https://docs.gradle.org/6.8.3/userguide/upgrading_version_5.html#dependencies_should_no_longer_be_declared_using_the_compile_and_runtime_configurations > The AbstractArchiveTask.baseName property has been deprecated. This is > scheduled to be removed in Gradle 7.0. Please use the archiveBaseName > property instead. See > https://docs.gradle.org/6.8.3/dsl/org.gradle.api.tasks.bundling.AbstractArchiveTask.html#org.gradle.api.tasks.bundling.AbstractArchiveTask:baseName > for more details. > The configuration :extensions:geode-modules:compileOnly was resolved without > accessing the project in a safe manner. This may happen when a configuration > is resolved from a different project. This behaviour has been deprecated and > is scheduled to be removed in Gradle 7.0. See > https://docs.gradle.org/6.8.3/userguide/viewing_debugging_dependencies.html#sub:resolving-unsafe-configuration-resolution-errors > for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335062#comment-17335062
]
ASF GitHub Bot commented on GEODE-9200:
---
pivotal-jbarrett commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622595152
##
File path: cppcache/src/CacheImpl.cpp
##
@@ -706,16 +706,16 @@ void CacheImpl::processMarker() {
if (!kv.second->isDestroyed()) {
if (const auto tcrHARegion =
std::dynamic_pointer_cast(kv.second)) {
-auto regionMsg = new TcrMessageClientMarker(
-new DataOutput(createDataOutput()), true);
-tcrHARegion->receiveNotification(regionMsg);
+tcrHARegion->receiveNotification(
+std::unique_ptr(new TcrMessageClientMarker(
+new DataOutput(createDataOutput()), true)));
Review comment:
Can we refactor away this constant `true` here?
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335053#comment-17335053 ] ASF subversion and git services commented on GEODE-8977: Commit 8d99d08dade997b0e530d5d7be29ef0e02645e2a in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8d99d08 ] GEODE-8977: improve thread monitor to log lock information (#6377) * Revert "Revert "GEODE-8977: include syncs in thread monitor stack (#6248)" (#6368)" This reverts commit f366940bb4172084412ff6943c3793a6e6ed1b77. * getThreadInfo is now called at most once each time the thread monitor wakes up. Before it was called once for every thread that might be stuck. > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335054#comment-17335054 ] ASF subversion and git services commented on GEODE-8977: Commit 8d99d08dade997b0e530d5d7be29ef0e02645e2a in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8d99d08 ] GEODE-8977: improve thread monitor to log lock information (#6377) * Revert "Revert "GEODE-8977: include syncs in thread monitor stack (#6248)" (#6368)" This reverts commit f366940bb4172084412ff6943c3793a6e6ed1b77. * getThreadInfo is now called at most once each time the thread monitor wakes up. Before it was called once for every thread that might be stuck. > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8977. - Fix Version/s: 1.15.0 Resolution: Fixed > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9211) Locator and server launcher have references to GemFire
[ https://issues.apache.org/jira/browse/GEODE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9211: -- Labels: pull-request-available (was: ) > Locator and server launcher have references to GemFire > -- > > Key: GEODE-9211 > URL: https://issues.apache.org/jira/browse/GEODE-9211 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > LocatorLauncher and ServerLauncher classes have a lot of references to > "GemFire" in Javadocs. They should be substituted by "Geode". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9209) Complete test in DistributionConfigJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9209: -- Labels: pull-request-available (was: ) > Complete test in DistributionConfigJUnitTest > > > Key: GEODE-9209 > URL: https://issues.apache.org/jira/browse/GEODE-9209 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > > testCheckerChecksValidAttribute in DistributionConfigJUnitTest has a "TODO" > comment about a missing check in the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9211) Locator and server launcher have references to GemFire
Alberto Bustamante Reyes created GEODE-9211: --- Summary: Locator and server launcher have references to GemFire Key: GEODE-9211 URL: https://issues.apache.org/jira/browse/GEODE-9211 Project: Geode Issue Type: Improvement Reporter: Alberto Bustamante Reyes LocatorLauncher and ServerLauncher classes have a lot of references to "GemFire" in Javadocs. They should be substituted by "Geode". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9211) Locator and server launcher have references to GemFire
[ https://issues.apache.org/jira/browse/GEODE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-9211: Priority: Minor (was: Major) > Locator and server launcher have references to GemFire > -- > > Key: GEODE-9211 > URL: https://issues.apache.org/jira/browse/GEODE-9211 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > LocatorLauncher and ServerLauncher classes have a lot of references to > "GemFire" in Javadocs. They should be substituted by "Geode". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9211) Locator and server launcher have references to GemFire
[ https://issues.apache.org/jira/browse/GEODE-9211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-9211: --- Assignee: Alberto Bustamante Reyes > Locator and server launcher have references to GemFire > -- > > Key: GEODE-9211 > URL: https://issues.apache.org/jira/browse/GEODE-9211 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > LocatorLauncher and ServerLauncher classes have a lot of references to > "GemFire" in Javadocs. They should be substituted by "Geode". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9079) Right-size Geode CI instances
[ https://issues.apache.org/jira/browse/GEODE-9079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335050#comment-17335050 ] ASF subversion and git services commented on GEODE-9079: Commit 3c2035cef0af5ff9925b491cdd3be963b5db8762 in geode's branch refs/heads/develop from Robert Houghton [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3c2035c ] GEODE-9079: downsize non-intentensive CI instances (#6206) * change how gradle home is synced from heavy-lifter to test archive * extend rsync timeout > Right-size Geode CI instances > - > > Key: GEODE-9079 > URL: https://issues.apache.org/jira/browse/GEODE-9079 > Project: Geode > Issue Type: Improvement > Components: build, ci >Reporter: Robert Houghton >Assignee: Robert Houghton >Priority: Major > Labels: pull-request-available > > Verify that heavy-lifter instances are utilizes well for their sizes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9071) CI Failure: PartitionedRegionCqQueryDUnitTest > testRemoveAllWithCQLocalDestroy
[
https://issues.apache.org/jira/browse/GEODE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335046#comment-17335046
]
Geode Integration commented on GEODE-9071:
--
Seen in [DistributedTestOpenJDK8
#173|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/173]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0175/test-results/distributedTest/1619643988/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0175/test-artifacts/1619643988/distributedtestfiles-OpenJDK8-1.15.0-build.0175.tgz].
> CI Failure: PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy
> ---
>
> Key: GEODE-9071
> URL: https://issues.apache.org/jira/browse/GEODE-9071
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy FAILED
> 10:10:22org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest$$Lambda$87/434016892.run
> in VM 2 running on Host bb8c1d338b8b with 4 VMs
> 10:10:22at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 10:10:22at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testRemoveAllWithCQLocalDestroy(PartitionedRegionCqQueryDUnitTest.java:243)
> 10:10:22
> 10:10:22Caused by:
> 10:10:22org.junit.ComparisonFailure: expected:<[999]> but was:<[645]>
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 10:10:22at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.lambda$testRemoveAllWithCQLocalDestroy$c93719d5$3(PartitionedRegionCqQueryDUnitTest.java:251)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335045#comment-17335045
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#166.4|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/166.4]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-results/distributedTest/1619635131/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-artifacts/1619635131/distributedtestfiles-OpenJDK8-1.15.0-build.0164.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9210) Move close keep alive flag unique to the cache
Jacob Barrett created GEODE-9210: Summary: Move close keep alive flag unique to the cache Key: GEODE-9210 URL: https://issues.apache.org/jira/browse/GEODE-9210 Project: Geode Issue Type: Sub-task Reporter: Jacob Barrett Currently the keep alive flag for closing the cache or a pool is global variable. This results in strange behavior when more than one cache exists in a process, which is very common in .NET app domain scenarios. Move the state to the cache and pools it is invoked on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9209) Complete test in DistributionConfigJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes updated GEODE-9209: Priority: Minor (was: Major) > Complete test in DistributionConfigJUnitTest > > > Key: GEODE-9209 > URL: https://issues.apache.org/jira/browse/GEODE-9209 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Minor > > testCheckerChecksValidAttribute in DistributionConfigJUnitTest has a "TODO" > comment about a missing check in the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9209) Complete test in DistributionConfigJUnitTest
Alberto Bustamante Reyes created GEODE-9209: --- Summary: Complete test in DistributionConfigJUnitTest Key: GEODE-9209 URL: https://issues.apache.org/jira/browse/GEODE-9209 Project: Geode Issue Type: Improvement Reporter: Alberto Bustamante Reyes testCheckerChecksValidAttribute in DistributionConfigJUnitTest has a "TODO" comment about a missing check in the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9209) Complete test in DistributionConfigJUnitTest
[ https://issues.apache.org/jira/browse/GEODE-9209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alberto Bustamante Reyes reassigned GEODE-9209: --- Assignee: Alberto Bustamante Reyes > Complete test in DistributionConfigJUnitTest > > > Key: GEODE-9209 > URL: https://issues.apache.org/jira/browse/GEODE-9209 > Project: Geode > Issue Type: Improvement >Reporter: Alberto Bustamante Reyes >Assignee: Alberto Bustamante Reyes >Priority: Major > > testCheckerChecksValidAttribute in DistributionConfigJUnitTest has a "TODO" > comment about a missing check in the test. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9204) A not serializable exception can cause a ServerConnection thread to get stuck waiting for a reply from another member
[
https://issues.apache.org/jira/browse/GEODE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9204:
--
Labels: pull-request-available (was: )
> A not serializable exception can cause a ServerConnection thread to get stuck
> waiting for a reply from another member
> -
>
> Key: GEODE-9204
> URL: https://issues.apache.org/jira/browse/GEODE-9204
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
>
> A test case that reproduces it is:
> - a client get request is received in one server and sent to another server
> - the other server uses a CacheLoader to load the value
> - the CacheLoader throws an exception containing a non-serializable object
> - the reply attempts to serialize that exception but fails with
> NotSerializableException
> - the original server's ServerConnection thread gets stuck waiting for a
> reply that will never come
> Here is a stack trace showing the NotSerializableException:
> {noformat}
> [severe 2018/03/20 14:30:27.793 PDT elgreco(85544):30177 unshared ordered uid=14 dom #1 port=53923>
> tid=0x5c] Uncaught exception processing partitioned.GetMessage(prid=2 (name
> = "/data") processorId=0; posDup=false; key=0; callback arg=null;
> context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
> java.lang.Object
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
> at
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
> at
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: java.lang.Object
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Updated] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9208:
--
Labels: pull-request-available (was: )
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Bug
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9208:
---
Priority: Minor (was: Major)
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Bug
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Minor
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9208:
---
Issue Type: Bug (was: Improvement)
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Bug
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
[
https://issues.apache.org/jira/browse/GEODE-9208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey reassigned GEODE-9208:
--
Assignee: Sarah Abbey
> StressNewTest doesn't pick up tests from all directories
>
>
> Key: GEODE-9208
> URL: https://issues.apache.org/jira/browse/GEODE-9208
> Project: Geode
> Issue Type: Improvement
> Components: build, ci, tests
>Affects Versions: 1.15.0
>Reporter: Sarah Abbey
>Assignee: Sarah Abbey
>Priority: Major
>
>
> When detecting which tests to run for StressNewTest, we use paths like the
> following:
> {code:java}
> '*/src/distributedTest/java'
> {code}
> This will pick up a file like this one:
> {code:java}
>
> geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
> {code}
> But won't pick up this file since the `src` dir here is more than one
> directory deep:
> {code:java}
> extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
>
> {code}
> We can use git's pathspec `:glob` keyword described
> [here|https://git-scm.com/docs/gitglossary] to pick up any number of
> directories preceding our desired path:
> {code:java}
> ':(glob)**/src/distributedTest/java/**'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9208) StressNewTest doesn't pick up tests from all directories
Sarah Abbey created GEODE-9208:
--
Summary: StressNewTest doesn't pick up tests from all directories
Key: GEODE-9208
URL: https://issues.apache.org/jira/browse/GEODE-9208
Project: Geode
Issue Type: Improvement
Components: build, ci, tests
Affects Versions: 1.15.0
Reporter: Sarah Abbey
When detecting which tests to run for StressNewTest, we use paths like the
following:
{code:java}
'*/src/distributedTest/java'
{code}
This will pick up a file like this one:
{code:java}
geode-assembly/src/distributedTest/java/org/apache/geode/session/tests/Jetty9CachingClientServerTest.java
{code}
But won't pick up this file since the `src` dir here is more than one directory
deep:
{code:java}
extensions/geode-modules/src/distributedTest/java/org/apache/geode/modules/util/ClientServerSessionCacheDUnitTest.java
{code}
We can use git's pathspec `:glob` keyword described
[here|https://git-scm.com/docs/gitglossary] to pick up any number of
directories preceding our desired path:
{code:java}
':(glob)**/src/distributedTest/java/**'
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9204) A not serializable exception can cause a ServerConnection thread to get stuck waiting for a reply from another member
[
https://issues.apache.org/jira/browse/GEODE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-9204:
--
Summary: A not serializable exception can cause a ServerConnection thread
to get stuck waiting for a reply from another member (was: A not serializable
object can cause a ServerConnection thread to get stuck waiting for a reply
from another member)
> A not serializable exception can cause a ServerConnection thread to get stuck
> waiting for a reply from another member
> -
>
> Key: GEODE-9204
> URL: https://issues.apache.org/jira/browse/GEODE-9204
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> A test case that reproduces it is:
> - a client get request is received in one server and sent to another server
> - the other server uses a CacheLoader to load the value
> - the CacheLoader throws an exception containing a non-serializable object
> - the reply attempts to serialize that exception but fails with
> NotSerializableException
> - the original server's ServerConnection thread gets stuck waiting for a
> reply that will never come
> Here is a stack trace showing the NotSerializableException:
> {noformat}
> [severe 2018/03/20 14:30:27.793 PDT elgreco(85544):30177 unshared ordered uid=14 dom #1 port=53923>
> tid=0x5c] Uncaught exception processing partitioned.GetMessage(prid=2 (name
> = "/data") processorId=0; posDup=false; key=0; callback arg=null;
> context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
> java.lang.Object
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
> at
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
> at
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: java.lang.Object
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
>
[jira] [Updated] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender updated GEODE-9193:
Parent: GEODE-9207
Issue Type: Sub-task (was: Bug)
> PING message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Sub-task
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[ https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender updated GEODE-9200: Parent: GEODE-9207 Issue Type: Sub-task (was: Bug) > Leaked message used to signal "all endpoints disconnected" > -- > > Key: GEODE-9200 > URL: https://issues.apache.org/jira/browse/GEODE-9200 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > Geode native uses a "blank" reply message to signal to regions that all > endpoints have disconnected, i.e. they can shut down. This message is > allocated on the heap into a static pointer in the function > `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a > dynamically allocated message, so it can be cleaned up via `delete` in the > region like all other messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9207) Eliminate use of static pointers for messages PING, CLOSE_CONNECTION, and "all endpoints disconnected" message
Blake Bender created GEODE-9207: --- Summary: Eliminate use of static pointers for messages PING, CLOSE_CONNECTION, and "all endpoints disconnected" message Key: GEODE-9207 URL: https://issues.apache.org/jira/browse/GEODE-9207 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender The binary format of these messages apparently doesn't change, and at some point someone thought it would be a great idea to just create each one time rather than call `new` or declare a variable on the stack. This actually leads to several instances of special-case code where we `delete` a pointer _unless_ it's one of these special ones, etc. Additionally, each of them is reported as leaked at shutdown by standard tracking tools. Stop treating these as special, this particular micro-optimization is not worth doing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335027#comment-17335027
]
ASF GitHub Bot commented on GEODE-9200:
---
pdxcodemonkey commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622585525
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2772,7 +2774,7 @@ void ThinClientRegion::receiveNotification(TcrMessage*
msg) {
}
lock.unlock();
- if (TcrMessage::getAllEPDisMess() != msg) _GEODE_SAFE_DELETE(msg);
+ _GEODE_SAFE_DELETE(msg);
Review comment:
This one was a little larger than I anticipated, but I think it's a
really nice refactor.
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335020#comment-17335020
]
ASF GitHub Bot commented on GEODE-9200:
---
pivotal-jbarrett commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622562195
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2967,7 +2969,8 @@ void ThinClientRegion::executeFunction(
} else if (err == GF_NOTCON) {
attempt++;
LOGDEBUG(
-"ThinClientRegion::executeFunction with GF_NOTCON retry attempt = "
+"ThinClientRegion::executeFunction with GF_NOTCON retry attempt "
Review comment:
That is even an odd one from clang-format on windows since it is
splitting a sting 2 characters shorter. 路
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335011#comment-17335011
]
ASF GitHub Bot commented on GEODE-9200:
---
pdxcodemonkey commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622551469
##
File path: cppcache/src/ThinClientPoolHADM.cpp
##
@@ -292,11 +293,11 @@ void
ThinClientPoolHADM::removeCallbackConnection(TcrEndpoint* ep) {
m_redundancyManager->removeCallbackConnection(ep);
}
-void ThinClientPoolHADM::sendNotConMesToAllregions() {
+void ThinClientPoolHADM::sendNotConnectedMessageToAllRegions() {
std::lock_guard guard(m_regionsLock);
for (std::list::iterator it = m_regions.begin();
Review comment:
Yep, fixed.
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9206) Remove unused static variable
[ https://issues.apache.org/jira/browse/GEODE-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9206: --- Description: While troubleshooting one issue having to do with static variables in ticket GEODE-9193, I noticed that there was an static variable which was unused and defined in the header file. Causing to be defined on each source that was used. So this task is intended to remove this static var. Find a report of all static variables: [^static_vars.txt] Also the procedure to extract the static variables is defined here: https://gist.github.com/gaussianrecurrence/8611cb029b46f1a413f4991f82781c36 was: While troubleshooting one issue having to do with static variables in ticket GEODE-9193, I noticed that there was an static variable which was unused and defined in the header file. Causing to be defined on each source that was used. So this task is intended to remove this static var. Find attached a report of all static variables. > Remove unused static variable > - > > Key: GEODE-9206 > URL: https://issues.apache.org/jira/browse/GEODE-9206 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: static_vars.txt > > > While troubleshooting one issue having to do with static variables in ticket > GEODE-9193, I noticed that there was an static variable which was unused and > defined in the header file. Causing to be defined on each source that was > used. > So this task is intended to remove this static var. > Find a report of all static variables: [^static_vars.txt] > Also the procedure to extract the static variables is defined here: > https://gist.github.com/gaussianrecurrence/8611cb029b46f1a413f4991f82781c36 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9206) Remove unused static variable
[ https://issues.apache.org/jira/browse/GEODE-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9206: -- Labels: pull-request-available (was: ) > Remove unused static variable > - > > Key: GEODE-9206 > URL: https://issues.apache.org/jira/browse/GEODE-9206 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > Attachments: static_vars.txt > > > While troubleshooting one issue having to do with static variables in ticket > GEODE-9193, I noticed that there was an static variable which was unused and > defined in the header file. Causing to be defined on each source that was > used. > So this task is intended to remove this static var. > Find attached a report of all static variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9206) Remove unused static variable
[ https://issues.apache.org/jira/browse/GEODE-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17335002#comment-17335002 ] ASF GitHub Bot commented on GEODE-9206: --- gaussianrecurrence opened a new pull request #794: URL: https://github.com/apache/geode-native/pull/794 - EMPTY_STRING seems not to be used and it's defined 267 times because it's within a header file. So this commit removes this static var. -- 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 > Remove unused static variable > - > > Key: GEODE-9206 > URL: https://issues.apache.org/jira/browse/GEODE-9206 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Attachments: static_vars.txt > > > While troubleshooting one issue having to do with static variables in ticket > GEODE-9193, I noticed that there was an static variable which was unused and > defined in the header file. Causing to be defined on each source that was > used. > So this task is intended to remove this static var. > Find attached a report of all static variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8862) DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs
[ https://issues.apache.org/jira/browse/GEODE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu resolved GEODE-8862. - Fix Version/s: 1.15.0 Resolution: Fixed > DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs > --- > > Key: GEODE-8862 > URL: https://issues.apache.org/jira/browse/GEODE-8862 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Affects Versions: 1.14.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > "vm_9_thr_27_persist8_host1_29953" #1448 daemon prio=5 os_prio=0 cpu=45.99ms > elapsed=698.42s tid=0x7f8d0c052800 nid=0x2ee8 waiting on condition > [0x7f8c354f6000] >java.lang.Thread.State: TIMED_WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base@11.0.9/Native Method) > - parking to wait for <0xfb7bb488> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.9/LockSupport.java:234) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1079) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1369) > at > java.util.concurrent.CountDownLatch.await(java.base@11.0.9/CountDownLatch.java:278) > at > org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) > at > org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857) > at > org.apache.geode.distributed.internal.locks.DLockRecoverGrantorProcessor.recoverLockGrantor(DLockRecoverGrantorProcessor.java:100) > at > org.apache.geode.distributed.internal.locks.DLockService.makeLocalGrantor(DLockService.java:447) > at > org.apache.geode.distributed.internal.locks.DLockService.createLocalGrantor(DLockService.java:392) > at > org.apache.geode.distributed.internal.locks.DLockService.getLockGrantorId(DLockService.java:337) > at > org.apache.geode.distributed.internal.locks.DLockService.lockInterruptibly(DLockService.java:1445) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1241) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1232) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1227) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1223) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.lock(PeerTypeRegistration.java:314) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.defineEnum(PeerTypeRegistration.java:646) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.getEnumId(PeerTypeRegistration.java:601) > at > org.apache.geode.pdx.internal.TypeRegistry.getEnumId(TypeRegistry.java:363) > at > org.apache.geode.internal.InternalDataSerializer.writePdxEnum(InternalDataSerializer.java:2071) > at > org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1610) > at > org.apache.geode.internal.InternalDataSerializer.writeWellKnownObject(InternalDataSerializer.java:1517) > at > org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2034) > at > org.apache.geode.pdx.internal.PdxOutputStream.writeObject(PdxOutputStream.java:72) > at > org.apache.geode.pdx.internal.PdxWriterImpl.writeObject(PdxWriterImpl.java:341) > at > org.apache.geode.pdx.internal.PdxWriterImpl.writeObject(PdxWriterImpl.java:330) > at util.VersionedValueHolder.myToData(VersionedValueHolder.java:227) > at > util.PdxVersionedValueHolder.toData(PdxVersionedValueHolder.java:84) > at > org.apache.geode.internal.InternalDataSerializer.writePdx(InternalDataSerializer.java:2794) > at > org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2011) > at > org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2839) > at >
[jira] [Commented] (GEODE-9175) Clean up the terminal output and log progress for benchmarks
[
https://issues.apache.org/jira/browse/GEODE-9175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334996#comment-17334996
]
ASF GitHub Bot commented on GEODE-9175:
---
pivotal-jbarrett commented on a change in pull request #147:
URL: https://github.com/apache/geode-benchmarks/pull/147#discussion_r622523533
##
File path:
harness/src/main/java/org/apache/geode/perftest/yardstick/YardstickTask.java
##
@@ -107,6 +112,35 @@ public String defaultDescription() {
runner.runBenchmark();
-testDoneProbe.await();
+Histogram lastHistogram = hdrHistogramProbe.getHistogram();
+while (!testDoneProbe.await(10, TimeUnit.SECONDS)) {
Review comment:
I won't fight you in throwing out yardstick. We have measured so much
variability in the framework itself. We have a no-op benchmark that swings by
as much last 15%. That is all noise from yardstick.
--
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
> Clean up the terminal output and log progress for benchmarks
>
>
> Key: GEODE-9175
> URL: https://issues.apache.org/jira/browse/GEODE-9175
> Project: Geode
> Issue Type: Improvement
> Components: benchmarks
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> When developing a new benchmark with geode-benchmarks or testing out code
> changes interactively, it would be nice to for the geode-benchmarks to log
> the current throughput and latency numbers as the test is running, similar to
> the way YCSB does.
> This lets someone writing a new benchmark quickly eyeball if the performance
> has changed, or if their warm up time is too short or too long because the
> throughput fluctuates.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8862) DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs
[ https://issues.apache.org/jira/browse/GEODE-8862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334995#comment-17334995 ] ASF subversion and git services commented on GEODE-8862: Commit 97700d3858d6dbc71c7d51769d5a3411d5bb7a5e in geode's branch refs/heads/develop from Eric Shu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=97700d3 ] GEODE-8862: Send grant message to remote node using waiting thread pool. (#6361) * In D_NO_ACK region, remote P2P reader thread may still be blocked handling the previous distriubted operation, and not able to handle the GRANT message. * Use executor waiting thread pool can avoid the potenial dead lock > DLockRecoverGrantorProcessor.recoverLockGrantor sometimes hangs > --- > > Key: GEODE-8862 > URL: https://issues.apache.org/jira/browse/GEODE-8862 > Project: Geode > Issue Type: Bug > Components: distributed lock service >Affects Versions: 1.14.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > "vm_9_thr_27_persist8_host1_29953" #1448 daemon prio=5 os_prio=0 cpu=45.99ms > elapsed=698.42s tid=0x7f8d0c052800 nid=0x2ee8 waiting on condition > [0x7f8c354f6000] >java.lang.Thread.State: TIMED_WAITING (parking) > at jdk.internal.misc.Unsafe.park(java.base@11.0.9/Native Method) > - parking to wait for <0xfb7bb488> (a > java.util.concurrent.CountDownLatch$Sync) > at > java.util.concurrent.locks.LockSupport.parkNanos(java.base@11.0.9/LockSupport.java:234) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1079) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(java.base@11.0.9/AbstractQueuedSynchronizer.java:1369) > at > java.util.concurrent.CountDownLatch.await(java.base@11.0.9/CountDownLatch.java:278) > at > org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72) > at > org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857) > at > org.apache.geode.distributed.internal.locks.DLockRecoverGrantorProcessor.recoverLockGrantor(DLockRecoverGrantorProcessor.java:100) > at > org.apache.geode.distributed.internal.locks.DLockService.makeLocalGrantor(DLockService.java:447) > at > org.apache.geode.distributed.internal.locks.DLockService.createLocalGrantor(DLockService.java:392) > at > org.apache.geode.distributed.internal.locks.DLockService.getLockGrantorId(DLockService.java:337) > at > org.apache.geode.distributed.internal.locks.DLockService.lockInterruptibly(DLockService.java:1445) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1241) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1232) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1227) > at > org.apache.geode.distributed.internal.locks.DLockService.lock(DLockService.java:1223) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.lock(PeerTypeRegistration.java:314) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.defineEnum(PeerTypeRegistration.java:646) > at > org.apache.geode.pdx.internal.PeerTypeRegistration.getEnumId(PeerTypeRegistration.java:601) > at > org.apache.geode.pdx.internal.TypeRegistry.getEnumId(TypeRegistry.java:363) > at > org.apache.geode.internal.InternalDataSerializer.writePdxEnum(InternalDataSerializer.java:2071) > at > org.apache.geode.internal.InternalDataSerializer.writeUserObject(InternalDataSerializer.java:1610) > at > org.apache.geode.internal.InternalDataSerializer.writeWellKnownObject(InternalDataSerializer.java:1517) > at > org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2034) > at > org.apache.geode.pdx.internal.PdxOutputStream.writeObject(PdxOutputStream.java:72) > at > org.apache.geode.pdx.internal.PdxWriterImpl.writeObject(PdxWriterImpl.java:341) > at > org.apache.geode.pdx.internal.PdxWriterImpl.writeObject(PdxWriterImpl.java:330) > at
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334991#comment-17334991
]
ASF GitHub Bot commented on GEODE-9200:
---
pdxcodemonkey commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622519109
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2672,25 +2672,29 @@ GfErrType
ThinClientRegion::clientNotificationHandler(TcrMessage& msg) {
LocalRegion::tombstoneOperationNoThrow(msg.getTombstoneVersions(),
msg.getTombstoneKeys());
break;
-default: {
- if (TcrMessage::getAllEPDisMess() == ) {
+default:
+ try {
+auto& marker =
+dynamic_cast(msg);
setProcessedMarker(false);
+LOGDEBUG(
+"ThinClientRegion::clientNotificationHandler: rec'd endpoints "
+"disconnected message");
LocalRegion::invokeAfterAllEndPointDisconnected();
- } else {
+ } catch (std::bad_cast) {
Review comment:
Yeah, LGTM griped at me about this one...
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334989#comment-17334989
]
ASF GitHub Bot commented on GEODE-9200:
---
pdxcodemonkey commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622518629
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2967,7 +2969,8 @@ void ThinClientRegion::executeFunction(
} else if (err == GF_NOTCON) {
attempt++;
LOGDEBUG(
-"ThinClientRegion::executeFunction with GF_NOTCON retry attempt = "
+"ThinClientRegion::executeFunction with GF_NOTCON retry attempt "
Review comment:
Really wish I knew why this was happening. It's as if `clang-format`
v11 on Windows is not exactly the same as `clang-format` v11 on other
platforms. It's frustrating.
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9206) Remove unused static variable
[ https://issues.apache.org/jira/browse/GEODE-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres updated GEODE-9206: --- Attachment: static_vars.txt > Remove unused static variable > - > > Key: GEODE-9206 > URL: https://issues.apache.org/jira/browse/GEODE-9206 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Attachments: static_vars.txt > > > While troubleshooting one issue having to do with static variables in ticket > GEODE-9193, I noticed that there was an static variable which was unused and > defined in the header file. Causing to be defined on each source that was > used. > So this task is intended to remove this static var. > Find attached a report of all static variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9206) Remove unused static variable
Mario Salazar de Torres created GEODE-9206: -- Summary: Remove unused static variable Key: GEODE-9206 URL: https://issues.apache.org/jira/browse/GEODE-9206 Project: Geode Issue Type: Task Components: native client Reporter: Mario Salazar de Torres While troubleshooting one issue having to do with static variables in ticket GEODE-9193, I noticed that there was an static variable which was unused and defined in the header file. Causing to be defined on each source that was used. So this task is intended to remove this static var. Find attached a report of all static variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9206) Remove unused static variable
[ https://issues.apache.org/jira/browse/GEODE-9206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9206: -- Assignee: Mario Salazar de Torres > Remove unused static variable > - > > Key: GEODE-9206 > URL: https://issues.apache.org/jira/browse/GEODE-9206 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > > While troubleshooting one issue having to do with static variables in ticket > GEODE-9193, I noticed that there was an static variable which was unused and > defined in the header file. Causing to be defined on each source that was > used. > So this task is intended to remove this static var. > Find attached a report of all static variables. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9189) Upgrade dependencies
[ https://issues.apache.org/jira/browse/GEODE-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334985#comment-17334985 ] ASF GitHub Bot commented on GEODE-9189: --- pivotal-jbarrett commented on pull request #790: URL: https://github.com/apache/geode-native/pull/790#issuecomment-828749976 Converted this back to draft again. There is one issue I want to resolve. CMake with either always update the git based projects on every compile or never unless forced by invoking the update target directly. I want to find a middle ground like a time based invocation, like no more than every 24h, similar to how Maven snapshots are updated. -- 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 > Upgrade dependencies > > > Key: GEODE-9189 > URL: https://issues.apache.org/jira/browse/GEODE-9189 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > Upgrade Boost to 1.76. > Upgrade ACE to 7.0.1. > Upgrade GTest to follow the head. > Upgrade Benchmark to follow the head. > Upgrade SQLite to 3.35.5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334982#comment-17334982
]
ASF GitHub Bot commented on GEODE-9200:
---
pivotal-jbarrett commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622502904
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2672,25 +2672,29 @@ GfErrType
ThinClientRegion::clientNotificationHandler(TcrMessage& msg) {
LocalRegion::tombstoneOperationNoThrow(msg.getTombstoneVersions(),
msg.getTombstoneKeys());
break;
-default: {
- if (TcrMessage::getAllEPDisMess() == ) {
+default:
+ try {
+auto& marker =
+dynamic_cast(msg);
setProcessedMarker(false);
+LOGDEBUG(
+"ThinClientRegion::clientNotificationHandler: rec'd endpoints "
+"disconnected message");
LocalRegion::invokeAfterAllEndPointDisconnected();
- } else {
+ } catch (std::bad_cast) {
Review comment:
```c++
} catch (std::bad_cast&) {
```
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[ https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334979#comment-17334979 ] ASF GitHub Bot commented on GEODE-9200: --- lgtm-com[bot] commented on pull request #793: URL: https://github.com/apache/geode-native/pull/793#issuecomment-828743251 This pull request **introduces 1 alert** when merging 42f79a127a85d72440582653acf1b68039451a79 into 0f40b8d8b5d530c5f650593526c01c0185d5efba - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode-native/rev/pr-20cf132a5d1054aef5f477c77fcd57c896561cc6) **new alerts:** * 1 for Catching by value -- 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 > Leaked message used to signal "all endpoints disconnected" > -- > > Key: GEODE-9200 > URL: https://issues.apache.org/jira/browse/GEODE-9200 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Assignee: Blake Bender >Priority: Major > Labels: pull-request-available > > Geode native uses a "blank" reply message to signal to regions that all > endpoints have disconnected, i.e. they can shut down. This message is > allocated on the heap into a static pointer in the function > `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a > dynamically allocated message, so it can be cleaned up via `delete` in the > region like all other messages. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334975#comment-17334975
]
ASF GitHub Bot commented on GEODE-9193:
---
pivotal-jbarrett commented on a change in pull request #792:
URL: https://github.com/apache/geode-native/pull/792#discussion_r622495428
##
File path: cppcache/src/TcrEndpoint.cpp
##
@@ -504,14 +504,15 @@ void TcrEndpoint::pingServer(ThinClientPoolDM* poolDM) {
}
if (!m_msgSent && !m_pingSent) {
-TcrMessagePing* pingMsg = TcrMessage::getPingMessage(m_cacheImpl);
+TcrMessagePing pingMsg(new DataOutput(m_cacheImpl->createDataOutput()),
+ true);
Review comment:
If this value is always `true` then let's just roll it into the
constructor initializer and remove from parameters.
##
File path: cppcache/src/TcrEndpoint.cpp
##
@@ -504,14 +504,15 @@ void TcrEndpoint::pingServer(ThinClientPoolDM* poolDM) {
}
if (!m_msgSent && !m_pingSent) {
-TcrMessagePing* pingMsg = TcrMessage::getPingMessage(m_cacheImpl);
+TcrMessagePing pingMsg(new DataOutput(m_cacheImpl->createDataOutput()),
Review comment:
Can you copy my PR where I modified the constructor to take a
`std::unique_ptr` to avoid any leaking potentials in allocating
here and failing to take ownership in the constructor. Also makes it more clean
who owns 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
> PING message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334970#comment-17334970
]
ASF GitHub Bot commented on GEODE-9200:
---
pivotal-jbarrett commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622488201
##
File path: cppcache/src/ThinClientPoolHADM.cpp
##
@@ -292,11 +293,11 @@ void
ThinClientPoolHADM::removeCallbackConnection(TcrEndpoint* ep) {
m_redundancyManager->removeCallbackConnection(ep);
}
-void ThinClientPoolHADM::sendNotConMesToAllregions() {
+void ThinClientPoolHADM::sendNotConnectedMessageToAllRegions() {
std::lock_guard guard(m_regionsLock);
for (std::list::iterator it = m_regions.begin();
Review comment:
Can this be changed to a for range loop?
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2967,7 +2969,8 @@ void ThinClientRegion::executeFunction(
} else if (err == GF_NOTCON) {
attempt++;
LOGDEBUG(
-"ThinClientRegion::executeFunction with GF_NOTCON retry attempt = "
+"ThinClientRegion::executeFunction with GF_NOTCON retry attempt "
Review comment:
More odd formatting changes.
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2772,7 +2774,7 @@ void ThinClientRegion::receiveNotification(TcrMessage*
msg) {
}
lock.unlock();
- if (TcrMessage::getAllEPDisMess() != msg) _GEODE_SAFE_DELETE(msg);
+ _GEODE_SAFE_DELETE(msg);
Review comment:
Any easy opportunity to make `msg` a smart pointer?
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -2723,12 +2727,12 @@ GfErrType ThinClientRegion::handleServerException(
"TransactionDataNodeHasDepartedException") !=
std::string::npos) {
error = GF_TRANSACTION_DATA_NODE_HAS_DEPARTED_EXCEPTION;
- } else if (exceptionMsg.find(
- "org.apache.geode.cache.TransactionDataRebalancedException")
!=
+ } else if (exceptionMsg.find("org.apache.geode.cache."
+ "TransactionDataRebalancedException") !=
Review comment:
This feels like an unintentional or at least less readable format change.
##
File path: cppcache/src/ThinClientRegion.cpp
##
@@ -3556,9 +3564,9 @@ void ChunkedFunctionExecutionResponse::handleChunk(
return;
}
- auto startLen = static_cast(
- input.getBytesRead() -
- 1); // from here need to look value part + memberid AND -1 for array
type
+ auto startLen = static_cast(input.getBytesRead() -
+ 1); // from here need to look value part
Review comment:
Move the comment above so the formatting is more readable.
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334931#comment-17334931
]
ASF GitHub Bot commented on GEODE-9193:
---
pdxcodemonkey commented on a change in pull request #792:
URL: https://github.com/apache/geode-native/pull/792#discussion_r622441292
##
File path: cppcache/src/TcrEndpoint.cpp
##
@@ -504,14 +504,15 @@ void TcrEndpoint::pingServer(ThinClientPoolDM* poolDM) {
}
if (!m_msgSent && !m_pingSent) {
-TcrMessagePing* pingMsg = TcrMessage::getPingMessage(m_cacheImpl);
+TcrMessagePing pingMsg(new DataOutput(m_cacheImpl->createDataOutput()),
Review comment:
Yeah - it's not pretty, but it is correct.
--
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 message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9164) User Guide - relocate Redis section to "Developing" from "Tools and Modules"
[ https://issues.apache.org/jira/browse/GEODE-9164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9164: -- Labels: pull-request-available (was: ) > User Guide - relocate Redis section to "Developing" from "Tools and Modules" > > > Key: GEODE-9164 > URL: https://issues.apache.org/jira/browse/GEODE-9164 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The section "Geode APIs Compatible with Redis" received a major rewrite > beginning with v1.14. For ease of access, relocate this section to > "Developing with Apache Geode" from "Tools & Modules". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334921#comment-17334921
]
ASF GitHub Bot commented on GEODE-9193:
---
gaussianrecurrence commented on a change in pull request #792:
URL: https://github.com/apache/geode-native/pull/792#discussion_r622427386
##
File path: cppcache/src/TcrEndpoint.cpp
##
@@ -504,14 +504,15 @@ void TcrEndpoint::pingServer(ThinClientPoolDM* poolDM) {
}
if (!m_msgSent && !m_pingSent) {
-TcrMessagePing* pingMsg = TcrMessage::getPingMessage(m_cacheImpl);
+TcrMessagePing pingMsg(new DataOutput(m_cacheImpl->createDataOutput()),
Review comment:
This pointer ownership is transfered to the TcrMessage by assigning it
to an unique_ptr. I am with you that the way of instantiating the object might
lead to think that this is a memory leak, but this is they way is done for most
of the TcrMessage implementations :S
--
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 message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9158) Implement CLUSTER NODES / SLOTS / INFO Command
[ https://issues.apache.org/jira/browse/GEODE-9158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334919#comment-17334919 ] ASF subversion and git services commented on GEODE-9158: Commit d7cf9676b6b5b252b69f0808c80fb19db6e32d83 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d7cf967 ] GEODE-9158: Add CLUSTER NODES, SLOTS and INFO commands (#6359) - None of the commands will return 'replica' information since Geode does make the distinction of a primary vs a secondary member. > Implement CLUSTER NODES / SLOTS / INFO Command > -- > > Key: GEODE-9158 > URL: https://issues.apache.org/jira/browse/GEODE-9158 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available, redis > > Implement the [CLUSTER NODES|https://redis.io/commands/cluster-nodes] command > as compatible with Redis. > Implement the [CLUSTER SLOTS|https://redis.io/commands/cluster-slots] command > as compatible with Redis. > Implement the [CLUSTER INFO|https://redis.io/commands/cluster-info] command > as compatible with Redis. > Consult the RFC for reference: > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Compatibility+with+Redis+data+sharding+and+cluster+changes] > +Acceptance Criteria+ > New DUnit tests are created to assert that the behavior is correct. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9195) Remove redundant local locking from PartitionedRegionClear
[
https://issues.apache.org/jira/browse/GEODE-9195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9195:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> Remove redundant local locking from PartitionedRegionClear
> --
>
> Key: GEODE-9195
> URL: https://issues.apache.org/jira/browse/GEODE-9195
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Existing behavior:
> PR clear unconditionally acquires a global lock and also acquires local locks
> on all buckets before doing clear.
> Expected behavior:
> Now that PR clear acquires a global lock, it no longer needs to acquire local
> locks on all buckets before doing clear.
> Solution:
> Remove the logic taking lock in individual nodes in:
> {noformat}
> DistributedRegion.obtainWriteLocksForClear()
> {noformat}
> Remove:
> {noformat}
> if (!localLockedAlready) {
> lockLocallyForClear(getDistributionManager(), getMyId(), regionEvent);
> }
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9198) Keystore/truststore file watcher does not follow symbolic links
[ https://issues.apache.org/jira/browse/GEODE-9198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Lindsey reassigned GEODE-9198: Assignee: Aaron Lindsey > Keystore/truststore file watcher does not follow symbolic links > --- > > Key: GEODE-9198 > URL: https://issues.apache.org/jira/browse/GEODE-9198 > Project: Geode > Issue Type: Bug >Reporter: Aaron Lindsey >Assignee: Aaron Lindsey >Priority: Major > Labels: pull-request-available > > GEODE-9017 introduced a file watching key/trust manager to automatically > reload the key and trust store upon change. However, the file watcher was > configured to not follow symbolic links. Some environments such as Kubernetes > use symbolic links to mount files inside a container file system. In cases > like this (where the key and trust store are represented using symbolic > links) the file watcher should follow these links and reload the key and > trust store when the underlying target file changes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9156) Switch from docker-compose to testcontainers
[ https://issues.apache.org/jira/browse/GEODE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334901#comment-17334901 ] ASF subversion and git services commented on GEODE-9156: Commit a5335756a5801adf35ffdf4635b51cb17757eb84 in geode's branch refs/heads/develop from Jens Deppe [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a533575 ] GEODE-9156: Replace docker-compose-rule with testcontainers in geode-connectors (#6378) > Switch from docker-compose to testcontainers > > > Key: GEODE-9156 > URL: https://issues.apache.org/jira/browse/GEODE-9156 > Project: Geode > Issue Type: Task > Components: membership >Reporter: Ernest Burghardt >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > > Palantir docker-compose-rule is sunsetting this month. Palantir advises > switching to testcontainers' docker compose integration. We already use > testcontainer... -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9141) Hang while shutting down a cache server due to corrupted message
[
https://issues.apache.org/jira/browse/GEODE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334900#comment-17334900
]
ASF subversion and git services commented on GEODE-9141:
Commit 9d0d4d1d33794d0f6a21c3bcae71e965cbbd7fbd in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9d0d4d1 ]
GEODE-9141: (2 of 2) Handle in-buffer concurrency
* Connection uses a ByteBufferVendor to mediate access to inputBuffer
* Prevent return to pool before socket closer is finished
> Hang while shutting down a cache server due to corrupted message
>
>
> Key: GEODE-9141
> URL: https://issues.apache.org/jira/browse/GEODE-9141
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.13.2, 1.14.0, 1.15.0
>Reporter: Bruce J Schuchardt
>Assignee: Bill Burcham
>Priority: Major
> Labels: blocks-1.14.0, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> We have a test that fails once in 5000 runs with a corrupted
> DestroyRegionMessage. It is always during CacheServer teardown when
> destroying a HARegionQueue Region.
> {noformat}
> "vm_0_thr_0_bridge_1_1_host1_6920" #144 daemon prio=5 os_prio=0
> tid=0x7fec70058800 nid=0x1d28 waiting on condition [0x7fec62063000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf4f654f8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeDestroyRegion(DistributedRegion.java:1865)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1844)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6180)
> at
> org.apache.geode.internal.cache.HARegion.destroyRegion(HARegion.java:331)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:476)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue.destroy(HARegionQueue.java:3438)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue$BlockingHARegionQueue.destroy(HARegionQueue.java:2272)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.destroyRQ(CacheClientProxy.java:1031)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.terminateDispatching(CacheClientProxy.java:939)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.shutdown(CacheClientNotifier.java:1306)
> - locked <0xf8022800> (a
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.close(AcceptorImpl.java:1630)
> - locked <0xf5f7b888> (a java.lang.Object)
> at
> org.apache.geode.internal.cache.CacheServerImpl.stop(CacheServerImpl.java:491)
> - locked <0xf7ef2980> (a
> org.apache.geode.internal.cache.CacheServerImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.stopServers(GemFireCacheImpl.java:2672)
> at
>
[jira] [Commented] (GEODE-9141) Hang while shutting down a cache server due to corrupted message
[
https://issues.apache.org/jira/browse/GEODE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334899#comment-17334899
]
ASF subversion and git services commented on GEODE-9141:
Commit 38a3540583a1d0a402b026ee0d33ae4b0a2907d3 in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=38a3540 ]
GEODE-9141: (1 of 2) rename ByteBufferSharingImpl to ByteBuferVendor
> Hang while shutting down a cache server due to corrupted message
>
>
> Key: GEODE-9141
> URL: https://issues.apache.org/jira/browse/GEODE-9141
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.13.2, 1.14.0, 1.15.0
>Reporter: Bruce J Schuchardt
>Assignee: Bill Burcham
>Priority: Major
> Labels: blocks-1.14.0, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> We have a test that fails once in 5000 runs with a corrupted
> DestroyRegionMessage. It is always during CacheServer teardown when
> destroying a HARegionQueue Region.
> {noformat}
> "vm_0_thr_0_bridge_1_1_host1_6920" #144 daemon prio=5 os_prio=0
> tid=0x7fec70058800 nid=0x1d28 waiting on condition [0x7fec62063000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf4f654f8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeDestroyRegion(DistributedRegion.java:1865)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1844)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6180)
> at
> org.apache.geode.internal.cache.HARegion.destroyRegion(HARegion.java:331)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:476)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue.destroy(HARegionQueue.java:3438)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue$BlockingHARegionQueue.destroy(HARegionQueue.java:2272)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.destroyRQ(CacheClientProxy.java:1031)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.terminateDispatching(CacheClientProxy.java:939)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.shutdown(CacheClientNotifier.java:1306)
> - locked <0xf8022800> (a
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.close(AcceptorImpl.java:1630)
> - locked <0xf5f7b888> (a java.lang.Object)
> at
> org.apache.geode.internal.cache.CacheServerImpl.stop(CacheServerImpl.java:491)
> - locked <0xf7ef2980> (a
> org.apache.geode.internal.cache.CacheServerImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.stopServers(GemFireCacheImpl.java:2672)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2263)
> - locked <0xf5a21a08> (a java.lang.Class for
>
[jira] [Commented] (GEODE-9180) Heartbeats Are Interrupted Inexplicably
[
https://issues.apache.org/jira/browse/GEODE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334897#comment-17334897
]
ASF subversion and git services commented on GEODE-9180:
Commit f8b07a007ac93c323cd888cbc53dc3914336077f in geode's branch
refs/heads/develop from Bill Burcham
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f8b07a0 ]
GEODE-9180: warn when heartbeat thread oversleeps (#6360)
* heartbeat producer logs warning when it oversleeps by a period or more
> Heartbeats Are Interrupted Inexplicably
> ---
>
> Key: GEODE-9180
> URL: https://issues.apache.org/jira/browse/GEODE-9180
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Sometimes we see a member force-disconnected and we see a preceding gap in
> the regular sequence of heartbeats generated by the member, but we can't
> explain why there was a gap. The explanation we are searching for is usually
> CPU saturation. We look for secondary evidence such as gaps in the regular
> sequence of statistics e.g. StatSampler sampleCount. When we can't find such
> secondary evidence, we can't, in good conscience, rule out bugs in the
> heartbeat generation logic itself.
> The heartbeat generation logic consists mainly of a thread that loops
> forever. Each time through the loop it sleeps for member-timeout /
> logical-interval. By default that's 5s / 2 = 2.5s. When it wakes up it sends
> unreliable UDP unicast messages to the coordinator and the two
> non-coordinator members to its "left" (earlier) in the view. If that
> heartbeat generation thread oversleeps or doesn't get adequate time slices
> when it's awake then heartbeats will be delayed. There will be gaps in the
> regular sequence.
> When this ticket is complete, a warning-level message will be logged if the
> heartbeat generation thread (see {{GMSHealthMonitor.startHeartbeatThread()}})
> oversleeps by more than the sleep interval (member-timeout /
> logical-interval), i.e. if it is asleep for more than 2 * (member-timeout /
> logical-interval), the warning will be logged.
> h3. See Also
> {{HostStatSampler}} generates messages like this:
> {quote}Statistics sampling thread detected a wakeup delay of 14318 ms,
> indicating a possible resource issue. Check the GC, memory, and CPU
> statistics.{quote}
> (from {{checkElapsedSleepTime}})
> The current ticket is needed because the actual thread of interest for
> heartbeat generation is the heartbeat-generation thread and sometimes it
> oversleeps when the stat sampler thread does not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9141) Hang while shutting down a cache server due to corrupted message
[
https://issues.apache.org/jira/browse/GEODE-9141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-9141.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> Hang while shutting down a cache server due to corrupted message
>
>
> Key: GEODE-9141
> URL: https://issues.apache.org/jira/browse/GEODE-9141
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Affects Versions: 1.13.2, 1.14.0, 1.15.0
>Reporter: Bruce J Schuchardt
>Assignee: Bill Burcham
>Priority: Major
> Labels: blocks-1.14.0, blocks-1.15.0, pull-request-available
> Fix For: 1.15.0
>
>
> We have a test that fails once in 5000 runs with a corrupted
> DestroyRegionMessage. It is always during CacheServer teardown when
> destroying a HARegionQueue Region.
> {noformat}
> "vm_0_thr_0_bridge_1_1_host1_6920" #144 daemon prio=5 os_prio=0
> tid=0x7fec70058800 nid=0x1d28 waiting on condition [0x7fec62063000]
>java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xf4f654f8> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277)
> at
> org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:72)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:723)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:794)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:771)
> at
> org.apache.geode.distributed.internal.ReplyProcessor21.waitForRepliesUninterruptibly(ReplyProcessor21.java:857)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.waitForAckIfNeeded(DistributedCacheOperation.java:779)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation._distribute(DistributedCacheOperation.java:676)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.startOperation(DistributedCacheOperation.java:277)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation.distribute(DistributedCacheOperation.java:318)
> at
> org.apache.geode.internal.cache.DistributedRegion.distributeDestroyRegion(DistributedRegion.java:1865)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1844)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6180)
> at
> org.apache.geode.internal.cache.HARegion.destroyRegion(HARegion.java:331)
> at
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:476)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue.destroy(HARegionQueue.java:3438)
> at
> org.apache.geode.internal.cache.ha.HARegionQueue$BlockingHARegionQueue.destroy(HARegionQueue.java:2272)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.destroyRQ(CacheClientProxy.java:1031)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientProxy.terminateDispatching(CacheClientProxy.java:939)
> at
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier.shutdown(CacheClientNotifier.java:1306)
> - locked <0xf8022800> (a
> org.apache.geode.internal.cache.tier.sockets.CacheClientNotifier)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.close(AcceptorImpl.java:1630)
> - locked <0xf5f7b888> (a java.lang.Object)
> at
> org.apache.geode.internal.cache.CacheServerImpl.stop(CacheServerImpl.java:491)
> - locked <0xf7ef2980> (a
> org.apache.geode.internal.cache.CacheServerImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.stopServers(GemFireCacheImpl.java:2672)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2263)
> - locked <0xf5a21a08> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2151)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1559)
> - locked
[jira] [Resolved] (GEODE-9139) SSLException in starting up a Locator
[
https://issues.apache.org/jira/browse/GEODE-9139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt resolved GEODE-9139.
---
Resolution: Fixed
> SSLException in starting up a Locator
> -
>
> Key: GEODE-9139
> URL: https://issues.apache.org/jira/browse/GEODE-9139
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> If you start up a locator using its host name, without a domain name, as a
> bind address you may get an SSLException in the form
> {noformat}
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative DNS name matching hostname.domainname found
> {noformat}
> The LocatorLauncher and InternalLocator throw away the bind address string
> and later do a reverse lookup to find the fully qualified hostname to use in
> endpoint identification matching.If the locator's own TLS certificate
> doesn't have the fully qualified name in it as a Subject Alternate Name the
> connection that the Locator makes to its own location service will fail.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9180) Heartbeats Are Interrupted Inexplicably
[
https://issues.apache.org/jira/browse/GEODE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham resolved GEODE-9180.
-
Resolution: Fixed
Fixed on develop. Will backport to 1.14, 1.13, 1.12…
> Heartbeats Are Interrupted Inexplicably
> ---
>
> Key: GEODE-9180
> URL: https://issues.apache.org/jira/browse/GEODE-9180
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Sometimes we see a member force-disconnected and we see a preceding gap in
> the regular sequence of heartbeats generated by the member, but we can't
> explain why there was a gap. The explanation we are searching for is usually
> CPU saturation. We look for secondary evidence such as gaps in the regular
> sequence of statistics e.g. StatSampler sampleCount. When we can't find such
> secondary evidence, we can't, in good conscience, rule out bugs in the
> heartbeat generation logic itself.
> The heartbeat generation logic consists mainly of a thread that loops
> forever. Each time through the loop it sleeps for member-timeout /
> logical-interval. By default that's 5s / 2 = 2.5s. When it wakes up it sends
> unreliable UDP unicast messages to the coordinator and the two
> non-coordinator members to its "left" (earlier) in the view. If that
> heartbeat generation thread oversleeps or doesn't get adequate time slices
> when it's awake then heartbeats will be delayed. There will be gaps in the
> regular sequence.
> When this ticket is complete, a warning-level message will be logged if the
> heartbeat generation thread (see {{GMSHealthMonitor.startHeartbeatThread()}})
> oversleeps by more than the sleep interval (member-timeout /
> logical-interval), i.e. if it is asleep for more than 2 * (member-timeout /
> logical-interval), the warning will be logged.
> h3. See Also
> {{HostStatSampler}} generates messages like this:
> {quote}Statistics sampling thread detected a wakeup delay of 14318 ms,
> indicating a possible resource issue. Check the GC, memory, and CPU
> statistics.{quote}
> (from {{checkElapsedSleepTime}})
> The current ticket is needed because the actual thread of interest for
> heartbeat generation is the heartbeat-generation thread and sometimes it
> oversleeps when the stat sampler thread does not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9180) Heartbeats Are Interrupted Inexplicably
[
https://issues.apache.org/jira/browse/GEODE-9180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Burcham updated GEODE-9180:
Fix Version/s: 1.15.0
> Heartbeats Are Interrupted Inexplicably
> ---
>
> Key: GEODE-9180
> URL: https://issues.apache.org/jira/browse/GEODE-9180
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Sometimes we see a member force-disconnected and we see a preceding gap in
> the regular sequence of heartbeats generated by the member, but we can't
> explain why there was a gap. The explanation we are searching for is usually
> CPU saturation. We look for secondary evidence such as gaps in the regular
> sequence of statistics e.g. StatSampler sampleCount. When we can't find such
> secondary evidence, we can't, in good conscience, rule out bugs in the
> heartbeat generation logic itself.
> The heartbeat generation logic consists mainly of a thread that loops
> forever. Each time through the loop it sleeps for member-timeout /
> logical-interval. By default that's 5s / 2 = 2.5s. When it wakes up it sends
> unreliable UDP unicast messages to the coordinator and the two
> non-coordinator members to its "left" (earlier) in the view. If that
> heartbeat generation thread oversleeps or doesn't get adequate time slices
> when it's awake then heartbeats will be delayed. There will be gaps in the
> regular sequence.
> When this ticket is complete, a warning-level message will be logged if the
> heartbeat generation thread (see {{GMSHealthMonitor.startHeartbeatThread()}})
> oversleeps by more than the sleep interval (member-timeout /
> logical-interval), i.e. if it is asleep for more than 2 * (member-timeout /
> logical-interval), the warning will be logged.
> h3. See Also
> {{HostStatSampler}} generates messages like this:
> {quote}Statistics sampling thread detected a wakeup delay of 14318 ms,
> indicating a possible resource issue. Check the GC, memory, and CPU
> statistics.{quote}
> (from {{checkElapsedSleepTime}})
> The current ticket is needed because the actual thread of interest for
> heartbeat generation is the heartbeat-generation thread and sometimes it
> oversleeps when the stat sampler thread does not.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9103) CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions FAILED
[
https://issues.apache.org/jira/browse/GEODE-9103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334858#comment-17334858
]
Geode Integration commented on GEODE-9103:
--
Seen in [DistributedTestOpenJDK8
#169.2|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/169.2]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-results/distributedTest/1619596258/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-artifacts/1619596258/distributedtestfiles-OpenJDK8-1.15.0-build.0167.tgz].
> CI Failure: PutAllClientServerDistributedTest.testPutAllReturnsExceptions
> FAILED
>
>
> Key: GEODE-9103
> URL: https://issues.apache.org/jira/browse/GEODE-9103
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>
> {noformat}
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest >
> testPutAllReturnsExceptions FAILED
> 17:13:44org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest$$Lambda$613/835527630.run
> in VM 2 running on Host de2767658753 with 4 VMs
> 17:13:44at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 17:13:44at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.testPutAllReturnsExceptions(PutAllClientServerDistributedTest.java:1956)
> 17:13:44
> 17:13:44Caused by:
> 17:13:44java.lang.AssertionError:
> 17:13:44Expecting actual throwable to be an instance of:
> 17:13:44 org.apache.geode.cache.client.ServerOperationException
> 17:13:44but was:
> 17:13:44 org.apache.geode.cache.client.ServerConnectivityException:
> Pool unexpected closed socket on server connection=Pooled Connection to
> de2767658753:36547,172.17.0.10(245):41001: Connection[DESTROYED]).
> Server unreachable: could not connect after 1 attempts
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:665)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:507)
> 17:13:44 at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:157)
> 17:13:44 ...(35 remaining lines not displayed - this can be
> changed with Assertions.setMaxStackTraceElementsDisplayed)
> 17:13:44at
> org.apache.geode.internal.cache.PutAllClientServerDistributedTest.lambda$testPutAllReturnsExceptions$bb17a952$6(PutAllClientServerDistributedTest.java:1961)
> 17:16 {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334857#comment-17334857
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#171.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/171.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0169/test-results/distributedTest/1619616839/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0169/test-artifacts/1619616839/distributedtestfiles-OpenJDK8-1.15.0-build.0169.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334855#comment-17334855
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#166.3|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/166.3]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-results/distributedTest/1619609479/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-artifacts/1619609479/distributedtestfiles-OpenJDK8-1.15.0-build.0164.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334856#comment-17334856
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#169.4|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/169.4]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-results/distributedTest/1619616761/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-artifacts/1619616761/distributedtestfiles-OpenJDK8-1.15.0-build.0167.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7122) CI failure: RedundancyLevelPart1DUnitTest testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-7122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334853#comment-17334853
]
Geode Integration commented on GEODE-7122:
--
Seen in [DistributedTestOpenJDK8
#166.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/166.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-results/distributedTest/1619573478/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-artifacts/1619573478/distributedtestfiles-OpenJDK8-1.15.0-build.0164.tgz].
> CI failure: RedundancyLevelPart1DUnitTest
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed
> with ComparisonFailure
> ---
>
> Key: GEODE-7122
> URL: https://issues.apache.org/jira/browse/GEODE-7122
> Project: Geode
> Issue Type: Bug
>Reporter: Benjamin P Ross
>Priority: Major
>
> RedundancyLevelPart1DUnitTest.
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest failed in
> DistributedTestOpenJDK8 build 1023:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1023
> {noformat}
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest >
> testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.RedundancyLevelPart1DUnitTest.testRedundancySpecifiedNonPrimaryEPFailsDetectionByRegisterInterest(RedundancyLevelPart1DUnitTest.java:256)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9163) Redis: update docs to reflect that the api is experimental
[ https://issues.apache.org/jira/browse/GEODE-9163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334840#comment-17334840 ] ASF subversion and git services commented on GEODE-9163: Commit b18836c424736092c38fc2bdbb7842b79c689f79 in geode's branch refs/heads/develop from John Hutchison [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b18836c ] GEODE-9163: Mark docs for apis compatible with Redis as experimental (#6374) > Redis: update docs to reflect that the api is experimental > -- > > Key: GEODE-9163 > URL: https://issues.apache.org/jira/browse/GEODE-9163 > Project: Geode > Issue Type: New Feature > Components: docs, redis >Affects Versions: 1.14.0, 1.15.0 >Reporter: Hale Bales >Priority: Major > Labels: pull-request-available > > update the docs to reflect that the Geode api compatible with Redis is still > experimental. This depends on GEODE-9162 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9201) Implement PUBSUB Command With All Subcommands
[ https://issues.apache.org/jira/browse/GEODE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9201: - Labels: redis (was: ) > Implement PUBSUB Command With All Subcommands > - > > Key: GEODE-9201 > URL: https://issues.apache.org/jira/browse/GEODE-9201 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > Labels: redis > > Implement the [PUBSUB|https://redis.io/commands/pubsub] command and the three > associated subcommands represented by subtasks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9201) Implement PUBSUB Command With All Subcommands
[ https://issues.apache.org/jira/browse/GEODE-9201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wayne updated GEODE-9201: - Summary: Implement PUBSUB Command With All Subcommands (was: Implement PUBSUB Command) > Implement PUBSUB Command With All Subcommands > - > > Key: GEODE-9201 > URL: https://issues.apache.org/jira/browse/GEODE-9201 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Wayne >Priority: Major > > Implement the [PUBSUB|https://redis.io/commands/pubsub] command and the three > associated subcommands represented by subtasks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9205) Implement NUMPAT Subcommand
Wayne created GEODE-9205: Summary: Implement NUMPAT Subcommand Key: GEODE-9205 URL: https://issues.apache.org/jira/browse/GEODE-9205 Project: Geode Issue Type: Sub-task Components: redis Reporter: Wayne Implement the [NUMPAT|https://redis.io/commands/pubsub#codepubsub-numpatcode] subcommand. +Acceptance Criteria+ The NUMPAT subcommand has been implemented and unit tests have been developed that assert that the command correctly returns the number of subscriptions to patterns (that are performed using the [PSUBSCRIBE|https://redis.io/commands/psubscribe] command). Note that this is not just the count of clients subscribed to patterns but the total number of patterns all the clients are subscribed to. h5. Return value [Integer reply|https://redis.io/topics/protocol#integer-reply]: the number of patterns all the clients are subscribed to. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9204) A not serializable object can cause a ServerConnection thread to get stuck waiting for a reply from another member
[
https://issues.apache.org/jira/browse/GEODE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt updated GEODE-9204:
--
Issue Type: Bug (was: Test)
> A not serializable object can cause a ServerConnection thread to get stuck
> waiting for a reply from another member
> --
>
> Key: GEODE-9204
> URL: https://issues.apache.org/jira/browse/GEODE-9204
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> A test case that reproduces it is:
> - a client get request is received in one server and sent to another server
> - the other server uses a CacheLoader to load the value
> - the CacheLoader throws an exception containing a non-serializable object
> - the reply attempts to serialize that exception but fails with
> NotSerializableException
> - the original server's ServerConnection thread gets stuck waiting for a
> reply that will never come
> Here is a stack trace showing the NotSerializableException:
> {noformat}
> [severe 2018/03/20 14:30:27.793 PDT elgreco(85544):30177 unshared ordered uid=14 dom #1 port=53923>
> tid=0x5c] Uncaught exception processing partitioned.GetMessage(prid=2 (name
> = "/data") processorId=0; posDup=false; key=0; callback arg=null;
> context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
> java.lang.Object
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
> at
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
> at
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: java.lang.Object
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
> at
>
[jira] [Assigned] (GEODE-9204) A not serializable object can cause a ServerConnection thread to get stuck waiting for a reply from another member
[
https://issues.apache.org/jira/browse/GEODE-9204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce J Schuchardt reassigned GEODE-9204:
-
Assignee: Bruce J Schuchardt
> A not serializable object can cause a ServerConnection thread to get stuck
> waiting for a reply from another member
> --
>
> Key: GEODE-9204
> URL: https://issues.apache.org/jira/browse/GEODE-9204
> Project: Geode
> Issue Type: Test
> Components: membership, messaging
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
>
> A test case that reproduces it is:
> - a client get request is received in one server and sent to another server
> - the other server uses a CacheLoader to load the value
> - the CacheLoader throws an exception containing a non-serializable object
> - the reply attempts to serialize that exception but fails with
> NotSerializableException
> - the original server's ServerConnection thread gets stuck waiting for a
> reply that will never come
> Here is a stack trace showing the NotSerializableException:
> {noformat}
> [severe 2018/03/20 14:30:27.793 PDT elgreco(85544):30177 unshared ordered uid=14 dom #1 port=53923>
> tid=0x5c] Uncaught exception processing partitioned.GetMessage(prid=2 (name
> = "/data") processorId=0; posDup=false; key=0; callback arg=null;
> context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
> java.lang.Object
> at
> org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
> at
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
> at
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
> at
> org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
> at
> org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
> at
> org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
> at
> org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
> at
> org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
> at
> org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: java.lang.Object
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
>
[jira] [Created] (GEODE-9204) A not serializable object can cause a ServerConnection thread to get stuck waiting for a reply from another member
Bruce J Schuchardt created GEODE-9204:
-
Summary: A not serializable object can cause a ServerConnection
thread to get stuck waiting for a reply from another member
Key: GEODE-9204
URL: https://issues.apache.org/jira/browse/GEODE-9204
Project: Geode
Issue Type: Test
Components: membership, messaging
Reporter: Bruce J Schuchardt
A test case that reproduces it is:
- a client get request is received in one server and sent to another server
- the other server uses a CacheLoader to load the value
- the CacheLoader throws an exception containing a non-serializable object
- the reply attempts to serialize that exception but fails with
NotSerializableException
- the original server's ServerConnection thread gets stuck waiting for a reply
that will never come
Here is a stack trace showing the NotSerializableException:
{noformat}
[severe 2018/03/20 14:30:27.793 PDT :30177 unshared ordered uid=14 dom #1 port=53923> tid=0x5c]
Uncaught exception processing partitioned.GetMessage(prid=2 (name = "/data")
processorId=0; posDup=false; key=0; callback arg=null;
context=identity(elgreco(client:85552:loner):53907:fce35145:client,connection=2)
org.apache.geode.InternalGemFireException: java.io.NotSerializableException:
java.lang.Object
at
org.apache.geode.internal.tcp.DirectReplySender.putOutgoing(DirectReplySender.java:76)
at
org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:109)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:392)
at
org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:376)
at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:386)
at
org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:449)
at
org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3872)
at
org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:3496)
at
org.apache.geode.distributed.internal.DistributionManager$MyListener.messageReceived(DistributionManager.java:4693)
at
org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.processMessage(JGroupMembershipManager.java:2128)
at
org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager.handleOrDeferMessage(JGroupMembershipManager.java:2037)
at
org.apache.geode.distributed.internal.membership.jgroup.JGroupMembershipManager$MyDCReceiver.messageReceived(JGroupMembershipManager.java:647)
at
org.apache.geode.distributed.internal.direct.DirectChannel.receive(DirectChannel.java:804)
at
org.apache.geode.internal.tcp.TCPConduit.messageReceived(TCPConduit.java:835)
at
org.apache.geode.internal.tcp.Connection.dispatchMessage(Connection.java:3932)
at
org.apache.geode.internal.tcp.Connection.processNIOBuffer(Connection.java:3515)
at
org.apache.geode.internal.tcp.Connection.runNioReader(Connection.java:1827)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1702)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.io.NotSerializableException: java.lang.Object
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
at java.lang.Throwable.writeObject(Throwable.java:985)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:1028)
at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
at
java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
at
[jira] [Commented] (GEODE-9189) Upgrade dependencies
[ https://issues.apache.org/jira/browse/GEODE-9189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334814#comment-17334814 ] ASF GitHub Bot commented on GEODE-9189: --- mmartell commented on pull request #790: URL: https://github.com/apache/geode-native/pull/790#issuecomment-828559408 I strongly agree with Abseil's "Live at Head" philiosophy, which appears to be largely adopted by Google's 250 million lines of C++. -- 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 > Upgrade dependencies > > > Key: GEODE-9189 > URL: https://issues.apache.org/jira/browse/GEODE-9189 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Assignee: Jacob Barrett >Priority: Major > Labels: pull-request-available > > Upgrade Boost to 1.76. > Upgrade ACE to 7.0.1. > Upgrade GTest to follow the head. > Upgrade Benchmark to follow the head. > Upgrade SQLite to 3.35.5 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334813#comment-17334813
]
ASF GitHub Bot commented on GEODE-9200:
---
pdxcodemonkey commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622304986
##
File path: cppcache/src/ThinClientPoolHADM.cpp
##
@@ -292,11 +293,11 @@ void
ThinClientPoolHADM::removeCallbackConnection(TcrEndpoint* ep) {
m_redundancyManager->removeCallbackConnection(ep);
}
-void ThinClientPoolHADM::sendNotConMesToAllregions() {
+void ThinClientPoolHADM::sendNotConnectedMessageToAllregions() {
Review comment:
Fixed. Nice catch!
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9193) PING message "leaked" at shutdown due to bad singleton implementation
[
https://issues.apache.org/jira/browse/GEODE-9193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334800#comment-17334800
]
ASF GitHub Bot commented on GEODE-9193:
---
mmartell commented on a change in pull request #792:
URL: https://github.com/apache/geode-native/pull/792#discussion_r622287890
##
File path: cppcache/src/TcrEndpoint.cpp
##
@@ -504,14 +504,15 @@ void TcrEndpoint::pingServer(ThinClientPoolDM* poolDM) {
}
if (!m_msgSent && !m_pingSent) {
-TcrMessagePing* pingMsg = TcrMessage::getPingMessage(m_cacheImpl);
+TcrMessagePing pingMsg(new DataOutput(m_cacheImpl->createDataOutput()),
Review comment:
Where is DataOutput deleted? Hopefully, that's not also a leak.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> PING message "leaked" at shutdown due to bad singleton implementation
> -
>
> Key: GEODE-9193
> URL: https://issues.apache.org/jira/browse/GEODE-9193
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> There is a micro-optimization in the native client to prevent creating and
> tearing down PING messages multiple times, since this message always has the
> same format. Unfortunately, the implementation uses a pointer, rather than a
> reference, so exactly one instance of TcrMessagePing is allocated on the
> heap, and the object is never deleted, making it appear as a leak in any
> leak-tracking tool.
> {code:java}
> TcrMessagePing* TcrMessage::getPingMessage(CacheImpl* cacheImpl) {
> static auto pingMsg = new TcrMessagePing(new
> DataOutput(cacheImpl->createDataOutput()), true);
> return pingMsg;
> } {code}
> Changing this from a pointer to a const reference will allow the object to be
> destructed properly at shutdown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9200) Leaked message used to signal "all endpoints disconnected"
[
https://issues.apache.org/jira/browse/GEODE-9200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334772#comment-17334772
]
ASF GitHub Bot commented on GEODE-9200:
---
mmartell commented on a change in pull request #793:
URL: https://github.com/apache/geode-native/pull/793#discussion_r622255695
##
File path: cppcache/src/ThinClientPoolHADM.cpp
##
@@ -292,11 +293,11 @@ void
ThinClientPoolHADM::removeCallbackConnection(TcrEndpoint* ep) {
m_redundancyManager->removeCallbackConnection(ep);
}
-void ThinClientPoolHADM::sendNotConMesToAllregions() {
+void ThinClientPoolHADM::sendNotConnectedMessageToAllregions() {
Review comment:
ToAllRegions not ToAllregions
--
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
> Leaked message used to signal "all endpoints disconnected"
> --
>
> Key: GEODE-9200
> URL: https://issues.apache.org/jira/browse/GEODE-9200
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Blake Bender
>Assignee: Blake Bender
>Priority: Major
> Labels: pull-request-available
>
> Geode native uses a "blank" reply message to signal to regions that all
> endpoints have disconnected, i.e. they can shut down. This message is
> allocated on the heap into a static pointer in the function
> `TcrMessage::getAllEPDisMess`, but is never deleted. This should be a
> dynamically allocated message, so it can be cleaned up via `delete` in the
> region like all other messages.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334666#comment-17334666
]
Geode Integration commented on GEODE-7710:
--
Seen in [DistributedTestOpenJDK8
#169.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/169.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-results/distributedTest/1619578698/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-artifacts/1619578698/distributedtestfiles-OpenJDK8-1.15.0-build.0167.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6183) CI Failure: LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed with ConditionTimeoutException
[ https://issues.apache.org/jira/browse/GEODE-6183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334665#comment-17334665 ] Geode Integration commented on GEODE-6183: -- Seen in [WindowsCoreIntegrationTestOpenJDK11 #162|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/162] ... see [test results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-results/integrationTest/1619576632/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-artifacts/1619576632/windows-coreintegrationtestfiles-OpenJDK11-1.15.0-build.0168.tgz]. > CI Failure: > LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles failed > with ConditionTimeoutException > > > Key: GEODE-6183 > URL: https://issues.apache.org/jira/browse/GEODE-6183 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Eric Shu >Assignee: Kirk Lund >Priority: Major > Time Spent: 5h 50m > Remaining Estimate: 0h > > Test failed in > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/223 > org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > > startDeletesStaleControlFiles FAILED > org.awaitility.core.ConditionTimeoutException: Assertion condition > defined as a lambda expression in > org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that > uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but > was:<[not responding]> within 300 seconds. > Caused by: > org.junit.ComparisonFailure: expected:<[online]> but was:<[not > responding]> -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9006) MemoryStatsNativeRedisAcceptanceTest CI failure
[
https://issues.apache.org/jira/browse/GEODE-9006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334663#comment-17334663
]
Geode Integration commented on GEODE-9006:
--
Seen in [AcceptanceTestOpenJDK11
#162|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/162]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-results/acceptanceTest/1619566192/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-artifacts/1619566192/acceptancetestfiles-OpenJDK11-1.15.0-build.0168.tgz].
> MemoryStatsNativeRedisAcceptanceTest CI failure
> ---
>
> Key: GEODE-9006
> URL: https://issues.apache.org/jira/browse/GEODE-9006
> Project: Geode
> Issue Type: New Feature
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Ray Ingles
>Assignee: John Hutchison
>Priority: Major
>
> CI failure:
> {{org.apache.geode.redis.internal.executor.server.MemoryStatsNativeRedisAcceptanceTest
> > usedMemory_shouldReflectActualMemoryUsage FAILED
> java.lang.AssertionError:
> Expecting:
> 854912L
> to be greater than:
> 855176L}}
> http://hydradb.gemfire.pivotal.io/hdb/testresult/9637883
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/AcceptanceTestOpenJDK11/builds/51
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9071) CI Failure: PartitionedRegionCqQueryDUnitTest > testRemoveAllWithCQLocalDestroy
[
https://issues.apache.org/jira/browse/GEODE-9071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334664#comment-17334664
]
Geode Integration commented on GEODE-9071:
--
Seen in [DistributedTestOpenJDK8
#167.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/167.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0165/test-results/distributedTest/1619575179/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0165/test-artifacts/1619575179/distributedtestfiles-OpenJDK8-1.15.0-build.0165.tgz].
> CI Failure: PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy
> ---
>
> Key: GEODE-9071
> URL: https://issues.apache.org/jira/browse/GEODE-9071
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Jens Deppe
>Priority: Major
>
> {noformat}
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest >
> testRemoveAllWithCQLocalDestroy FAILED
> 10:10:22org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest$$Lambda$87/434016892.run
> in VM 2 running on Host bb8c1d338b8b with 4 VMs
> 10:10:22at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> 10:10:22at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.testRemoveAllWithCQLocalDestroy(PartitionedRegionCqQueryDUnitTest.java:243)
> 10:10:22
> 10:10:22Caused by:
> 10:10:22org.junit.ComparisonFailure: expected:<[999]> but was:<[645]>
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 10:10:22at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 10:10:22at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 10:10:22at
> org.apache.geode.cache.query.cq.dunit.PartitionedRegionCqQueryDUnitTest.lambda$testRemoveAllWithCQLocalDestroy$c93719d5$3(PartitionedRegionCqQueryDUnitTest.java:251)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-results/distributedTest/1616696789/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0082/test-artifacts/1616696789/distributedtestfiles-OpenJDK8-1.15.0-build.0082.tgz
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334661#comment-17334661
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#171|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/171]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0169/test-results/distributedTest/1619599825/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0169/test-artifacts/1619599825/distributedtestfiles-OpenJDK8-1.15.0-build.0169.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334660#comment-17334660
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#166.2|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/166.2]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-results/distributedTest/1619588075/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0164/test-artifacts/1619588075/distributedtestfiles-OpenJDK8-1.15.0-build.0164.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334662#comment-17334662
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#169.3|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/169.3]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-results/distributedTest/1619608205/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0167/test-artifacts/1619608205/distributedtestfiles-OpenJDK8-1.15.0-build.0167.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8990) CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
[
https://issues.apache.org/jira/browse/GEODE-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334659#comment-17334659
]
Geode Integration commented on GEODE-8990:
--
Seen in [DistributedTestOpenJDK8
#170|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/170]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-results/distributedTest/1619587319/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0168/test-artifacts/1619587319/distributedtestfiles-OpenJDK8-1.15.0-build.0168.tgz].
> CI Failure: Jetty9CachingClientServerTest.shouldCacheSessionOnClient
>
>
> Key: GEODE-8990
> URL: https://issues.apache.org/jira/browse/GEODE-8990
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Benjamin P Ross
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest >
> shouldCacheSessionOnClient FAILED
> org.junit.ComparisonFailure: expected:<[Foo]> but was:<[bogus]>
> at org.junit.Assert.assertEquals(Assert.java:117)
> at org.junit.Assert.assertEquals(Assert.java:146)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:65)
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-results/distributedTest/1614646829/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0023/test-artifacts/1614646829/distributedtestfiles-OpenJDK8-1.15.0-build.0023.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9174) The result of a gfsh query containing a UUID may not be displayed properly
[
https://issues.apache.org/jira/browse/GEODE-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17334482#comment-17334482
]
ASF subversion and git services commented on GEODE-9174:
Commit 465173cf7de037239f08b27921066fd84e8cc1f9 in geode's branch
refs/heads/develop from Mario Kevo
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=465173c ]
GEODE-9174: fix displaying the result of a gfsh query containing a UUID (#6365)
> The result of a gfsh query containing a UUID may not be displayed properly
> --
>
> Key: GEODE-9174
> URL: https://issues.apache.org/jira/browse/GEODE-9174
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> For example, if the key is a UUID, then a query like this won't show the
> results even though there is one:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> {noformat}
> But a query like this will:
> {noformat}
> gfsh>query --query="select key,value from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> key | value
> -- |
> ---
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c" |
> {"id":"55e907b6-a1fe-42ea-90a2-6a5698e9b27c","cusip":"AAPL","shares":22,"price":352.32}
> {noformat}
> Thats because of the way {{DataCommandResult.resolveObjectToColumns}} works.
> {noformat}
> private void resolveObjectToColumns(Map columnData, Object
> value) {
> if (value instanceof PdxInstance) {
> resolvePdxToColumns(columnData, (PdxInstance) value);
> } else if (value instanceof Struct) {
> resolveStructToColumns(columnData, (StructImpl) value);
> } else {
> ObjectMapper mapper = new ObjectMapper();
> JsonNode node = mapper.valueToTree(value);
> node.fieldNames().forEachRemaining(field -> {
> ...
> columnData.put(field, mapper.writeValueAsString(node.get(field)));
> });
> }
> }
> {noformat}
> The value in the first query is a {{UUID}} so the last else clause is
> invoked. In this case, a {{JsonNode}} is used to determine the columns.
> {{ObjectMapper.valueToTree}} converts a {{UUID}} to a {{TextNode}}.
> {{TextNodes}} have no fieldNames, and {{JsonNode.fieldNames}} returns an
> {{EmptyIterator}} by default:
> {noformat}
> public Iterator fieldNames() {
> return ClassUtil.emptyIterator();
> }
> {noformat}
> So, {{resolveObjectToColumns}} doesn't fill in columnData, which causes the
> {{DataCommandResult.buildTable}} in the locator to not add any rows to the
> table.
> The value in the second query is a {{Struct}} so the second else clause is
> invoked. The {{resolveStructToColumns}} method does:
> {noformat}
> private void resolveStructToColumns(Map columnData,
> StructImpl struct) {
> for (String field : struct.getFieldNames()) {
> columnData.put(field, valueToJson(struct.get(field)));
> }
> }
> {noformat}
> I'm not sure if there is a way to make {{ObjectMapper.valueToTree}} handle
> {{UUIDs}} differently, but they can easily be special-cased like
> {{PdxInstances}} and {{Structs}}:
> {noformat}
> } else if (value instanceof UUID) {
> columnData.put("uuid", valueToJson(value));
> {noformat}
> I'm not sure if this is the best solution, but it works. With this clause
> added, the query does:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> uuid
> --
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9174) The result of a gfsh query containing a UUID may not be displayed properly
[
https://issues.apache.org/jira/browse/GEODE-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9174.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> The result of a gfsh query containing a UUID may not be displayed properly
> --
>
> Key: GEODE-9174
> URL: https://issues.apache.org/jira/browse/GEODE-9174
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> For example, if the key is a UUID, then a query like this won't show the
> results even though there is one:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> {noformat}
> But a query like this will:
> {noformat}
> gfsh>query --query="select key,value from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> key | value
> -- |
> ---
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c" |
> {"id":"55e907b6-a1fe-42ea-90a2-6a5698e9b27c","cusip":"AAPL","shares":22,"price":352.32}
> {noformat}
> Thats because of the way {{DataCommandResult.resolveObjectToColumns}} works.
> {noformat}
> private void resolveObjectToColumns(Map columnData, Object
> value) {
> if (value instanceof PdxInstance) {
> resolvePdxToColumns(columnData, (PdxInstance) value);
> } else if (value instanceof Struct) {
> resolveStructToColumns(columnData, (StructImpl) value);
> } else {
> ObjectMapper mapper = new ObjectMapper();
> JsonNode node = mapper.valueToTree(value);
> node.fieldNames().forEachRemaining(field -> {
> ...
> columnData.put(field, mapper.writeValueAsString(node.get(field)));
> });
> }
> }
> {noformat}
> The value in the first query is a {{UUID}} so the last else clause is
> invoked. In this case, a {{JsonNode}} is used to determine the columns.
> {{ObjectMapper.valueToTree}} converts a {{UUID}} to a {{TextNode}}.
> {{TextNodes}} have no fieldNames, and {{JsonNode.fieldNames}} returns an
> {{EmptyIterator}} by default:
> {noformat}
> public Iterator fieldNames() {
> return ClassUtil.emptyIterator();
> }
> {noformat}
> So, {{resolveObjectToColumns}} doesn't fill in columnData, which causes the
> {{DataCommandResult.buildTable}} in the locator to not add any rows to the
> table.
> The value in the second query is a {{Struct}} so the second else clause is
> invoked. The {{resolveStructToColumns}} method does:
> {noformat}
> private void resolveStructToColumns(Map columnData,
> StructImpl struct) {
> for (String field : struct.getFieldNames()) {
> columnData.put(field, valueToJson(struct.get(field)));
> }
> }
> {noformat}
> I'm not sure if there is a way to make {{ObjectMapper.valueToTree}} handle
> {{UUIDs}} differently, but they can easily be special-cased like
> {{PdxInstances}} and {{Structs}}:
> {noformat}
> } else if (value instanceof UUID) {
> columnData.put("uuid", valueToJson(value));
> {noformat}
> I'm not sure if this is the best solution, but it works. With this clause
> added, the query does:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> uuid
> --
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
