[jira] [Assigned] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres reassigned GEODE-9753: -- Assignee: Mario Salazar de Torres > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439191#comment-17439191 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9753: -- Labels: needsTriage pull-request-available (was: needsTriage) > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439247#comment-17439247
]
ASF subversion and git services commented on GEODE-9778:
Commit 7f4bf62a08b24aca81fe05349cdc72d919a6cab7 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=7f4bf62 ]
GEODE-9778: Bump netty from 4.1.67.Final to 4.1.70.Final (#7075)
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439321#comment-17439321 ] ASF subversion and git services commented on GEODE-9291: Commit df05773d4994bcd95973e88af2b2ea473e88d711 in geode-benchmarks's branch refs/heads/develop from Eric Zoerner [ https://gitbox.apache.org/repos/asf?p=geode-benchmarks.git;h=df05773 ] GEODE-9291: Add benchmark for Zrem (#160) > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439322#comment-17439322 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-9797: -- Assignee: Dave Barnes > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9797: - Labels: needsTriage (was: ) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Priority: Major > Labels: needsTriage > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9797) User guide typo repairs
Dave Barnes created GEODE-9797: -- Summary: User guide typo repairs Key: GEODE-9797 URL: https://issues.apache.org/jira/browse/GEODE-9797 Project: Geode Issue Type: Bug Components: docs Affects Versions: 1.14.0, 1.13.4, 1.12.5 Reporter: Dave Barnes An eagle-eyed community member reports the following typographical errors: http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html Paragraph 3: "intialization" should be "initialization" http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-9797: --- Priority: Minor (was: Major) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Priority: Minor > Labels: needsTriage > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9797: -- Labels: needsTriage pull-request-available (was: needsTriage) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439365#comment-17439365 ] ASF subversion and git services commented on GEODE-9797: Commit 96ea7b9271355d337713d212f9f980f8ce0e5cab in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=96ea7b9 ] GEODE-9797: User guide typo repairs (#7085) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9781) changed all geode-for-redis system properties to use RedisProperties
[ https://issues.apache.org/jira/browse/GEODE-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9781. - Fix Version/s: 1.15.0 Resolution: Fixed > changed all geode-for-redis system properties to use RedisProperties > > > Key: GEODE-9781 > URL: https://issues.apache.org/jira/browse/GEODE-9781 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > geode-for-redis has system properties in it (like "redis.region.buckets" on > RegionProvider) that should all be changed to use RedisProperties. > Also RedisProperties should use a private final static for the common prefix > "geode-for-redis-". > Also RedisProperties should log a warning if it decides to ignore a property > and go with a default because the value of the property is not valid (for > example when it can't be parsed as an integer). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9781) changed all geode-for-redis system properties to use RedisProperties
[ https://issues.apache.org/jira/browse/GEODE-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439370#comment-17439370 ] ASF subversion and git services commented on GEODE-9781: Commit eea10019d65f68b9ab1303762f568844e1755bbd in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=eea1001 ] GEODE-9781: clean up radish sys props (#7080) * all geode-for-redis system property names are now defined in RedisProperties. A check is now done that the property name has the required prefix. Warnings are logged if the system property is set to a value that will not be used. * AuthIntegrationTest was trying to test with a non-default region name by setting the system property "REDIS_REGION_NAME_PROPERTY" in setupCacheWithRegionName. But this actually did nothing and geode still used the default. The problem was that the constant was not actually the name of the system property. It now is and this test should now be using a non-default region name. * if the bucket sys prop is greater than 16384 it will now log a warning and use the default number of buckets. It used to fail the redis server startup. * RedisPropertiesTest now uses RestoreSystemProperties rule > changed all geode-for-redis system properties to use RedisProperties > > > Key: GEODE-9781 > URL: https://issues.apache.org/jira/browse/GEODE-9781 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > geode-for-redis has system properties in it (like "redis.region.buckets" on > RegionProvider) that should all be changed to use RedisProperties. > Also RedisProperties should use a private final static for the common prefix > "geode-for-redis-". > Also RedisProperties should log a warning if it decides to ignore a property > and go with a default because the value of the property is not valid (for > example when it can't be parsed as an integer). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439406#comment-17439406 ] ASF subversion and git services commented on GEODE-9797: Commit 120165b9dc188e5f212fa7347636f7a3070cc988 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=120165b ] GEODE-9797: User guide typo repairs (#7085) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner resolved GEODE-9291. - Fix Version/s: 1.15.0 Resolution: Fixed > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9796) CI Failure: reap-benchmark-instances fails with invalid JAVA_HOME
[
https://issues.apache.org/jira/browse/GEODE-9796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-9796.
-
Fix Version/s: 1.15.0
Resolution: Fixed
worked around the alpine/docker/concourse cgroups issue by changing -x to -f in
benchmarks' gradle wrapper.
> CI Failure: reap-benchmark-instances fails with invalid JAVA_HOME
> -
>
> Key: GEODE-9796
> URL: https://issues.apache.org/jira/browse/GEODE-9796
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Owen Nichols
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> The job fails with the following error:
> {noformat}
> ERROR: JAVA_HOME is set to an invalid directory:
> /usr/lib/jvm/jdk-8u312-bellsoft-x86_64
> Please set the JAVA_HOME variable in your environment to match the
> location of your Java installation.
> {noformat}
> Link to the first failed concourse run:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-reaper/jobs/reap-benchmark-instances/builds/1090
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439421#comment-17439421 ] ASF subversion and git services commented on GEODE-9797: Commit f0f5e48d100fbad33faa3d8001847ac121e000cd in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0f5e48 ] GEODE-9797: User guide typo repairs (#7085) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439423#comment-17439423 ] ASF subversion and git services commented on GEODE-9797: Commit 00aad0ed326466e9b85add7353b1061acf450af0 in geode's branch refs/heads/support/1.13 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=00aad0e ] GEODE-9797: User guide typo repairs (#7085) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439424#comment-17439424 ] ASF subversion and git services commented on GEODE-9797: Commit 2e252746bf30e475c3a3a5292153c4b85f58c414 in geode's branch refs/heads/support/1.12 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2e25274 ] GEODE-9797: User guide typo repairs (#7085) > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9788) Develop PubSub Benchmark Tests
[ https://issues.apache.org/jira/browse/GEODE-9788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Zoerner reassigned GEODE-9788: --- Assignee: Eric Zoerner > Develop PubSub Benchmark Tests > -- > > Key: GEODE-9788 > URL: https://issues.apache.org/jira/browse/GEODE-9788 > Project: Geode > Issue Type: Test > Components: redis >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > > Develop a suite of benchmarking tests for the pubsub API that benchmark the > comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the pubsub that allows us to monitor the performance over time and compared > to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9797) User guide typo repairs
[ https://issues.apache.org/jira/browse/GEODE-9797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-9797. Fix Version/s: 1.15.0 1.14.1 1.13.5 1.12.6 Resolution: Fixed > User guide typo repairs > --- > > Key: GEODE-9797 > URL: https://issues.apache.org/jira/browse/GEODE-9797 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.12.5, 1.13.4, 1.14.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Minor > Labels: needsTriage, pull-request-available > Fix For: 1.12.6, 1.13.5, 1.14.1, 1.15.0 > > > An eagle-eyed community member reports the following typographical errors: > http://geode.apache.org/docs/guide/114/managing/security/authentication_examples.html > Paragraph 3: "intialization" should be "initialization" > http://geode.apache.org/docs/guide/114/managing/security/implementing_authentication.html > Paragraph 6 (or so): "in the clear" should be "in cleartext" -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439442#comment-17439442 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439447#comment-17439447
]
ASF GitHub Bot commented on GEODE-9291:
---
nonbinaryprogrammer commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743246628
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
I'm not a huge fan of creating a sorted set then turning around and
deleting that same sorted set. Have you considered adding a random key and then
removing a random key? There are definitely some potential issues there (ie
always getting unlucky and removing a key that doesn't exist, resulting in more
creates than deletes, or conversely getting unlucky when adding a sorted set
and colliding with one that exists already, causing more removes than adds), I
just want to make sure that this is the best test that we can do given these
issues.
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of
> the Leaderboard API that allows us to monitor the performance over time and
> compared to native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439451#comment-17439451 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439453#comment-17439453
]
ASF GitHub Bot commented on GEODE-9291:
---
ezoerner commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743258356
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
> Have you considered adding a random key and then removing a random
key?
This is what is actually happening. A random long is being fetched from the
entire key range, but that long is then broken apart using `toKey` and `toPart`
to get a top-level key and a value which is the value that goes into the sorted
set itself. The `RedisSplitKey` class used to be named `RedisHash` because it
was used for hashes to split the long value into a top-level key and a
hash-key. I re-used this code for sorted sets. I renamed it to "split key" so
that it wasn't specific to hashes but can be used for any kind of container
data type that contains values. It essentially splits a random long value into
a key and a sub-part. I struggled a little bit to find a good name for this
that would be self-evident without requiring a bunch of extra comments in the
code, but maybe more explanation about is going on here in code comments would
help(?)
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility w
[jira] [Resolved] (GEODE-9778) Benchmark degradation in RedisHsetBenchmark since netty bump
[
https://issues.apache.org/jira/browse/GEODE-9778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe resolved GEODE-9778.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Benchmark degradation in RedisHsetBenchmark since netty bump
>
>
> Key: GEODE-9778
> URL: https://issues.apache.org/jira/browse/GEODE-9778
> Project: Geode
> Issue Type: Bug
> Components: benchmarks, redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> examples:
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/179]
> #179 seems to show a consistent 10-15% degradation in only in the Hset
> benchmark
> {noformat}
> ...
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:234210.78 Test:207591.61 Difference: -11.4%
> avg latency
> Baseline: 3070166.30 Test: 3468289.49 Difference: +13.0%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:238884.30 Test:216618.91 Difference: -9.3%
> avg latency
> Baseline: 3016750.52 Test: 3319615.79 Difference: +10.0%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:248656.29 Test:211220.74 Difference: -15.1%
> avg latency
> Baseline: 2894368.00 Test: 3405200.04 Difference: +17.6% {noformat}
>
> Also
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-radish/builds/180]
> shows similar results:
> {noformat}
> This is ITERATION 2 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:146409.80 Test:134019.47 Difference: -8.5%
> avg latency
> Baseline: 4914049.28 Test: 5365514.18 Difference: +9.2%
> RedisHsetBenchmark avg ops/sec
> Baseline:217729.26 Test:191512.40 Difference: -12.0%
> avg latency
> Baseline: 3302672.13 Test: 3750731.05 Difference: +13.6%
> This is ITERATION 3 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:141960.20 Test:129616.40 Difference: -8.7%
> avg latency
> Baseline: 5065570.96 Test: 5554949.31 Difference: +9.7%
> RedisHsetBenchmark avg ops/sec
> Baseline:219985.85 Test:199572.01 Difference: -9.3%
> avg latency
> Baseline: 3268138.34 Test: 3603197.51 Difference: +10.3%
> This is ITERATION 4 of benchmarking against baseline.
> RedisHsetAndHgetBenchmark avg ops/sec
> Baseline:140404.88 Test:134341.05 Difference: -4.3%
> avg latency
> Baseline: 5127629.59 Test: 5354599.94 Difference: +4.4%
> RedisHsetBenchmark avg ops/sec
> Baseline:224728.82 Test:194024.96 Difference: -13.7%
> avg latency
> Baseline: 3205365.68 Test: 3706058.86 Difference: +15.6%
> This is ITERATION 5 of benchmarking against baseline.
> RedisHsetBenchmark avg ops/sec
> Baseline:220019.47 Test:192107.91 Difference: -12.7%
> avg latency
> Baseline: 3268273.76 Test: 3744842.51 Difference: +14.6%
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9798) javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code
[ https://issues.apache.org/jira/browse/GEODE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9798: - Labels: needsTriage (was: ) > javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to > internal code > --- > > Key: GEODE-9798 > URL: https://issues.apache.org/jira/browse/GEODE-9798 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: needsTriage > > The deprecation javadocs on > PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT tells users to use > PartitionAttributesImpl.getLocalMaxMemoryDefault() instead. Non-internal > javadocs should never refer to internal APIs. Geode does not have an > alternative way of computing this default value statically. The only problem > with the deprecated constant is that it is wrong for off-heap regions. The > deprecation tag should just mention this and not tell you about any other api > you can use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9798) javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code
[ https://issues.apache.org/jira/browse/GEODE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9798: Priority: Minor (was: Major) > javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to > internal code > --- > > Key: GEODE-9798 > URL: https://issues.apache.org/jira/browse/GEODE-9798 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Minor > Labels: needsTriage > > The deprecation javadocs on > PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT tells users to use > PartitionAttributesImpl.getLocalMaxMemoryDefault() instead. Non-internal > javadocs should never refer to internal APIs. Geode does not have an > alternative way of computing this default value statically. The only problem > with the deprecated constant is that it is wrong for off-heap regions. The > deprecation tag should just mention this and not tell you about any other api > you can use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9798) javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code
Darrel Schneider created GEODE-9798: --- Summary: javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code Key: GEODE-9798 URL: https://issues.apache.org/jira/browse/GEODE-9798 Project: Geode Issue Type: Bug Components: core Reporter: Darrel Schneider The deprecation javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT tells users to use PartitionAttributesImpl.getLocalMaxMemoryDefault() instead. Non-internal javadocs should never refer to internal APIs. Geode does not have an alternative way of computing this default value statically. The only problem with the deprecated constant is that it is wrong for off-heap regions. The deprecation tag should just mention this and not tell you about any other api you can use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9798) javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code
[ https://issues.apache.org/jira/browse/GEODE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9798: Affects Version/s: 1.12.0 > javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to > internal code > --- > > Key: GEODE-9798 > URL: https://issues.apache.org/jira/browse/GEODE-9798 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0 >Reporter: Darrel Schneider >Priority: Minor > Labels: needsTriage > > The deprecation javadocs on > PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT tells users to use > PartitionAttributesImpl.getLocalMaxMemoryDefault() instead. Non-internal > javadocs should never refer to internal APIs. Geode does not have an > alternative way of computing this default value statically. The only problem > with the deprecated constant is that it is wrong for off-heap regions. The > deprecation tag should just mention this and not tell you about any other api > you can use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9798) javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to internal code
[ https://issues.apache.org/jira/browse/GEODE-9798?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439462#comment-17439462 ] Darrel Schneider commented on GEODE-9798: - this is just a javadoc issue. I has been around in all geode releases > javadocs on PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT refers to > internal code > --- > > Key: GEODE-9798 > URL: https://issues.apache.org/jira/browse/GEODE-9798 > Project: Geode > Issue Type: Bug > Components: core >Affects Versions: 1.12.0 >Reporter: Darrel Schneider >Priority: Minor > Labels: needsTriage > > The deprecation javadocs on > PartitionAttributesFactory.LOCAL_MAX_MEMORY_DEFAULT tells users to use > PartitionAttributesImpl.getLocalMaxMemoryDefault() instead. Non-internal > javadocs should never refer to internal APIs. Geode does not have an > alternative way of computing this default value statically. The only problem > with the deprecated constant is that it is wrong for off-heap regions. The > deprecation tag should just mention this and not tell you about any other api > you can use. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[ https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439480#comment-17439480 ] ASF GitHub Bot commented on GEODE-9291: --- DonalEvans merged pull request #160: URL: https://github.com/apache/geode-benchmarks/pull/160 -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Develop Benchmarking Tests for Leaderboard API > -- > > Key: GEODE-9291 > URL: https://issues.apache.org/jira/browse/GEODE-9291 > Project: Geode > Issue Type: Test > Components: redis >Affects Versions: 1.15.0 >Reporter: Wayne >Assignee: Eric Zoerner >Priority: Major > Labels: pull-request-available, redis > Fix For: 1.15.0 > > > Develop a suite of benchmarking tests for the Leaderboard API that benchmark > the comparison between native Redis and the compatibility with Redis layer. > +Acceptance Criteria+ > A benchmark should be developed that provides acceptable coverage (TBD) of > the Leaderboard API that allows us to monitor the performance over time and > compared to native Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9799) javadocs describing PartitionRegion's local-max-memory misleading
Darrel Schneider created GEODE-9799: --- Summary: javadocs describing PartitionRegion's local-max-memory misleading Key: GEODE-9799 URL: https://issues.apache.org/jira/browse/GEODE-9799 Project: Geode Issue Type: Improvement Components: core Reporter: Darrel Schneider The javadocs on for local-max-memory say: "the maximum amount of local memory that can be used by the Region". This is not true. The region can use more memory. The javadocs on PartitionAttributes.getLocalMaxMemory and PartitionAttributesFactory.setLocalMaxMemory should be improved. The geode docs do a better job of describing this feature. In most cases don't bother setting local-max-memory. In some rare cases you may want to set it to 0 so that certain server do not store any of the region's data. Here is the geode docs (I find it saying "set aside" confusing because Geode does not actually do that): bq. Maximum megabytes of memory set aside for this region in the local member. This is all memory used for this partitioned region - for primary buckets and any redundant copies. This value must be smaller than the Java settings for the initial or maximum JVM heap. When the memory use goes above this value, Geode issues a warning, but operation continues. Besides setting the maximum memory to use for the member, this setting also tells Geode how to balance the load between members where the region is defined. For example, if one member sets this value to twice the value of another member’s setting, Geode works to keep the ratio between the first and the second at two-to-one, regardless of how little memory the region consumes. This is a local parameter that applies only to the local member. A value of 0 disables local data caching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9799) javadocs describing PartitionRegion's local-max-memory misleading
[ https://issues.apache.org/jira/browse/GEODE-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9799: Priority: Minor (was: Major) > javadocs describing PartitionRegion's local-max-memory misleading > - > > Key: GEODE-9799 > URL: https://issues.apache.org/jira/browse/GEODE-9799 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Priority: Minor > > The javadocs on for local-max-memory say: "the maximum amount of local memory > that can be used by the Region". This is not true. The region can use more > memory. The javadocs on PartitionAttributes.getLocalMaxMemory and > PartitionAttributesFactory.setLocalMaxMemory should be improved. The geode > docs do a better job of describing this feature. In most cases don't bother > setting local-max-memory. In some rare cases you may want to set it to 0 so > that certain server do not store any of the region's data. Here is the geode > docs (I find it saying "set aside" confusing because Geode does not actually > do that): > bq. Maximum megabytes of memory set aside for this region in the local > member. This is all memory used for this partitioned region - for primary > buckets and any redundant copies. This value must be smaller than the Java > settings for the initial or maximum JVM heap. When the memory use goes above > this value, Geode issues a warning, but operation continues. Besides setting > the maximum memory to use for the member, this setting also tells Geode how > to balance the load between members where the region is defined. For example, > if one member sets this value to twice the value of another member’s setting, > Geode works to keep the ratio between the first and the second at two-to-one, > regardless of how little memory the region consumes. This is a local > parameter that applies only to the local member. A value of 0 disables local > data caching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9799) javadocs describing PartitionRegion's local-max-memory misleading
[ https://issues.apache.org/jira/browse/GEODE-9799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9799: Affects Version/s: 1.12.0 > javadocs describing PartitionRegion's local-max-memory misleading > - > > Key: GEODE-9799 > URL: https://issues.apache.org/jira/browse/GEODE-9799 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.12.0 >Reporter: Darrel Schneider >Priority: Minor > > The javadocs on for local-max-memory say: "the maximum amount of local memory > that can be used by the Region". This is not true. The region can use more > memory. The javadocs on PartitionAttributes.getLocalMaxMemory and > PartitionAttributesFactory.setLocalMaxMemory should be improved. The geode > docs do a better job of describing this feature. In most cases don't bother > setting local-max-memory. In some rare cases you may want to set it to 0 so > that certain server do not store any of the region's data. Here is the geode > docs (I find it saying "set aside" confusing because Geode does not actually > do that): > bq. Maximum megabytes of memory set aside for this region in the local > member. This is all memory used for this partitioned region - for primary > buckets and any redundant copies. This value must be smaller than the Java > settings for the initial or maximum JVM heap. When the memory use goes above > this value, Geode issues a warning, but operation continues. Besides setting > the maximum memory to use for the member, this setting also tells Geode how > to balance the load between members where the region is defined. For example, > if one member sets this value to twice the value of another member’s setting, > Geode works to keep the ratio between the first and the second at two-to-one, > regardless of how little memory the region consumes. This is a local > parameter that applies only to the local member. A value of 0 disables local > data caching. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439487#comment-17439487
]
ASF GitHub Bot commented on GEODE-9291:
---
nonbinaryprogrammer commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743246628
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
I'm not a huge fan of creating a sorted set then turning around and
deleting that same sorted set. Have you considered adding a random key and then
removing a random key? There are definitely some potential issues there (ie
always getting unlucky and removing a key that doesn't exist, resulting in more
creates than deletes, or conversely getting unlucky when adding a sorted set
and colliding with one that exists already, causing more removes than adds), I
just want to make sure that this is the best test that we can do given these
issues.
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility with Redis layer.
> +Acceptance Criteria+
> A benchmark should be developed that provides acceptable coverage (TBD) of
> the Leaderboard API that allows us to monitor the performance over time and
> compared to native Redis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9767) bump netty to recommended version
[ https://issues.apache.org/jira/browse/GEODE-9767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9767: - Labels: pull-request-available (was: needsTriage pull-request-available) > bump netty to recommended version > - > > Key: GEODE-9767 > URL: https://issues.apache.org/jira/browse/GEODE-9767 > Project: Geode > Issue Type: Bug > Components: redis >Affects Versions: 1.12.5, 1.13.4, 1.14.0, 1.15.0 >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > > latest is 4.1.69, we should be using 4.1.68 or 4.1.69 on all branches if > possible -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9753) Coredump during PdxSerializable object serialization
[ https://issues.apache.org/jira/browse/GEODE-9753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439491#comment-17439491 ] ASF GitHub Bot commented on GEODE-9753: --- gaussianrecurrence opened a new pull request #891: URL: https://github.com/apache/geode-native/pull/891 - While serializing a PdxSerializable object, there is a possible race condition which might cause the client to crash. This race-condition happens whenever the cluster is restarted during the serialization process and if on-client-disconnect-clear-pdxType-Ids is set to true, meaning the PdxTypeRegistry will be cleaned up if the connection towards the cluster is lost. - This issue has been solved by using the previously fetched local PDX type. - In order to properly test this solution, PdxRemoteWriterFactory has been added, so the race-condition can be force at test-time. - A new IT has been added to test that the solution is working fine. - make_unique was needed inside cppcache/src, so it was moved to utils/cxx_extensions.hpp - Also in order to ease the use of newer C++ standard a preprocessor check was added to make_unique, so if the used standard >= C++14, the standard implementation of make_unique will be used instead. -- 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. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Coredump during PdxSerializable object serialization > > > Key: GEODE-9753 > URL: https://issues.apache.org/jira/browse/GEODE-9753 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: needsTriage, pull-request-available > > *GIVEN* **a single server and locator cluster with 1 PdxSerializable class > registered, named Order > *AND* a geode-native client with 1 PdxSerializable 1 PdxSerializable class > registered, named Order > *WHEN* a Order object is tried to be serialized > *WHILE* the cluster is being restarted > *THEN* a coredump happens due to PdxType=nullptr > — > *Additional information*. As seen by early troubleshooting, the coredump > happens because the pdx type is tried to be fetched from the PdxTypeRegist by > its class name, but the PdxTypeRegistry is cleaned up during serialization > given that subscription redundancy was lost. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9291) Develop Benchmarking Tests for Leaderboard API
[
https://issues.apache.org/jira/browse/GEODE-9291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439492#comment-17439492
]
ASF GitHub Bot commented on GEODE-9291:
---
ezoerner commented on a change in pull request #160:
URL: https://github.com/apache/geode-benchmarks/pull/160#discussion_r743258356
##
File path:
geode-benchmarks/src/main/java/org/apache/geode/benchmark/redis/tasks/ZaddAndZremRedisTask.java
##
@@ -0,0 +1,72 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+package org.apache.geode.benchmark.redis.tasks;
+
+
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toKey;
+import static org.apache.geode.benchmark.redis.tasks.RedisSplitKey.toPart;
+
+import java.io.Serializable;
+import java.util.Map;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+import org.yardstickframework.BenchmarkConfiguration;
+import org.yardstickframework.BenchmarkDriverAdapter;
+
+import org.apache.geode.benchmark.LongRange;
+
+public class ZaddAndZremRedisTask extends BenchmarkDriverAdapter implements
Serializable {
+ private static final Logger logger =
LoggerFactory.getLogger(ZaddAndZremRedisTask.class);
+
+ private final RedisClientManager redisClientManager;
+ private final LongRange keyRange;
+
+ private transient LongStringCache keyCache;
+ private transient RedisClient redisClient;
+
+ public ZaddAndZremRedisTask(final RedisClientManager redisClientManager,
+ final LongRange keyRange) {
+logger.info("Initialized: keyRange={}", keyRange);
+this.redisClientManager = redisClientManager;
+this.keyRange = keyRange;
+ }
+
+ @Override
+ public void setUp(final BenchmarkConfiguration cfg) throws Exception {
+super.setUp(cfg);
+
+keyCache = new LongStringCache(keyRange);
+redisClient = redisClientManager.get();
+ }
+
+ private static String NEXT_KEY = "N";
+
+ @Override
+ public boolean test(final Map ctx) throws Exception {
+final long k = keyRange.random();
+
+final String key = keyCache.valueOf(toKey(k));
+final long score = toPart(k);
+final String value = keyCache.valueOf(score);
+redisClient.zadd(key, score, value);
+redisClient.zrem(key, value);
Review comment:
> Have you considered adding a random key and then removing a random
key?
This is what is actually happening. A random long is being fetched from the
entire key range, but that long is then broken apart using `toKey` and `toPart`
to get a top-level key and a value which is the value that goes into the sorted
set itself. The `RedisSplitKey` class used to be named `RedisHash` because it
was used for hashes to split the long value into a top-level key and a
hash-key. I re-used this code for sorted sets. I renamed it to "split key" so
that it wasn't specific to hashes but can be used for any kind of container
data type that contains values. It essentially splits a random long value into
a key and a sub-part. I struggled a little bit to find a good name for this
that would be self-evident without requiring a bunch of extra comments in the
code, but maybe more explanation about is going on here in code comments would
help(?)
--
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.
To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Develop Benchmarking Tests for Leaderboard API
> --
>
> Key: GEODE-9291
> URL: https://issues.apache.org/jira/browse/GEODE-9291
> Project: Geode
> Issue Type: Test
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Assignee: Eric Zoerner
>Priority: Major
> Labels: pull-request-available, redis
> Fix For: 1.15.0
>
>
> Develop a suite of benchmarking tests for the Leaderboard API that benchmark
> the comparison between native Redis and the compatibility w
[jira] [Created] (GEODE-9800) improve radish info maxmemory and used_memory
Darrel Schneider created GEODE-9800: --- Summary: improve radish info maxmemory and used_memory Key: GEODE-9800 URL: https://issues.apache.org/jira/browse/GEODE-9800 Project: Geode Issue Type: Improvement Components: redis Reporter: Darrel Schneider Currently the radish INFO command returns values for maxmemory and used_memory that are not as helpful as they could be. For maxmemory it returns PartitionedRegion.getLocalMaxMemory. That is just a hint to geode to help it decide which server should get a new bucket. It in no ways limits how much data can be stored in the region. But radish also stores things in the server that do not go in a region (pubsub info). So maxmemory should instead be equal to java.lang.Runtime.maxMemory(). For used_memory it return dataStore.currentAllocatedMemory(). But that only shows how much data is stored in the region locally (and is only an estimate of that) so once again does not account for pubsub or for all the extra overhead we have in our radish implementation. So instead it should return Runtime.maxMemory()-Runtime.freeMemory(). Note that Runtime.totalMemory() should not be used since some jvms set totalMemory to maxMemory. Even when that is done freeMemory() has a meaningful value so max-free is a good estimate of "used_memory". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9800) improve radish info maxmemory and used_memory
[ https://issues.apache.org/jira/browse/GEODE-9800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9800: Affects Version/s: 1.15.0 > improve radish info maxmemory and used_memory > - > > Key: GEODE-9800 > URL: https://issues.apache.org/jira/browse/GEODE-9800 > Project: Geode > Issue Type: Improvement > Components: redis >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > > Currently the radish INFO command returns values for maxmemory and > used_memory that are not as helpful as they could be. > For maxmemory it returns PartitionedRegion.getLocalMaxMemory. That is just a > hint to geode to help it decide which server should get a new bucket. It in > no ways limits how much data can be stored in the region. But radish also > stores things in the server that do not go in a region (pubsub info). So > maxmemory should instead be equal to java.lang.Runtime.maxMemory(). > For used_memory it return dataStore.currentAllocatedMemory(). But that only > shows how much data is stored in the region locally (and is only an estimate > of that) so once again does not account for pubsub or for all the extra > overhead we have in our radish implementation. So instead it should return > Runtime.maxMemory()-Runtime.freeMemory(). Note that Runtime.totalMemory() > should not be used since some jvms set totalMemory to maxMemory. Even when > that is done freeMemory() has a meaningful value so max-free is a good > estimate of "used_memory". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9801) CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are not accurate
[
https://issues.apache.org/jira/browse/GEODE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-9801:
-
Labels: needsTriage (was: )
> CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
> not accurate
>
>
> Key: GEODE-9801
> URL: https://issues.apache.org/jira/browse/GEODE-9801
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.0
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This issue has been around since Geode 1.0.
> CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
> supposed to help geode users figure out how much memory is being used by
> tombstones. But because of some over sites in the sizing code they actual
> amount of memory used by tombstones is significantly higher. Some of the
> mistakes made:
> 1. A Tombstone is added to a ConcurrentLinkedQueue. This is accounted for as
> a single objRef. But each add to a ConcurrentLinkedQueue add a Node instance
> so you have the object header size plus two objRefs.
> 2. The size of the RegionEntry is not accounted for. The size of the key in
> this entry is but most of the memory used is in the RegionEntry fields
> itself. And the key, in some cases, is stored inline in primitive fields in
> the RegionEntry so Tombstone.getSize should not be asking the RegionEntry for
> its key and then sizing it but should instead just ask the RegionEntry for
> its memory footprint. It can then figure out if it needs to size any of the
> objects it references (like the key).
> 3. the Tombstone class it self accounts for all its fields but forgot about
> its own object header.
> To fix this have the Tombstone class add the following:
> {code:java}
> private static final TOMBSTONE_OVERHEAD =
> JvmSizeUtils.memoryOverhead(Tombstone.class);
> {code}
> For the Node overhead on ConcurrentLinkedQueue add this:
> {code:java}
> private static final NODE_OVERHEAD =
> JvmSizeUtils.roundUpSize(JvmSizeUtils.getObjectHeaderSize() +
> 2*JvmSizeUtils.getReferenceSize());
> {code}
> For RegionEntry add a new "memoryOverhead" method on RegionEntry and then
> implement it in all the many leaf classes. You can do this by modifying
> LeafRegionEntry.cpp and running generateRegionEntryClasses.sh. You will want
> each class to have a private static final field that calls
> JvmSizeUtils.memoryOverhead(.class) and then decide at runtime if
> the instance references other objects that should be sized (like key, value,
> DiskId, etc.).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9801) CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are not accurate
Darrel Schneider created GEODE-9801:
---
Summary: CachePerfStats.replicatedTombstonesSize and
nonReplicatedTombstonesSize are not accurate
Key: GEODE-9801
URL: https://issues.apache.org/jira/browse/GEODE-9801
Project: Geode
Issue Type: Bug
Components: core
Affects Versions: 1.12.0
Reporter: Darrel Schneider
This issue has been around since Geode 1.0.
CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
supposed to help geode users figure out how much memory is being used by
tombstones. But because of some over sites in the sizing code they actual
amount of memory used by tombstones is significantly higher. Some of the
mistakes made:
1. A Tombstone is added to a ConcurrentLinkedQueue. This is accounted for as a
single objRef. But each add to a ConcurrentLinkedQueue add a Node instance so
you have the object header size plus two objRefs.
2. The size of the RegionEntry is not accounted for. The size of the key in
this entry is but most of the memory used is in the RegionEntry fields itself.
And the key, in some cases, is stored inline in primitive fields in the
RegionEntry so Tombstone.getSize should not be asking the RegionEntry for its
key and then sizing it but should instead just ask the RegionEntry for its
memory footprint. It can then figure out if it needs to size any of the objects
it references (like the key).
3. the Tombstone class it self accounts for all its fields but forgot about its
own object header.
To fix this have the Tombstone class add the following:
{code:java}
private static final TOMBSTONE_OVERHEAD =
JvmSizeUtils.memoryOverhead(Tombstone.class);
{code}
For the Node overhead on ConcurrentLinkedQueue add this:
{code:java}
private static final NODE_OVERHEAD =
JvmSizeUtils.roundUpSize(JvmSizeUtils.getObjectHeaderSize() +
2*JvmSizeUtils.getReferenceSize());
{code}
For RegionEntry add a new "memoryOverhead" method on RegionEntry and then
implement it in all the many leaf classes. You can do this by modifying
LeafRegionEntry.cpp and running generateRegionEntryClasses.sh. You will want
each class to have a private static final field that calls
JvmSizeUtils.memoryOverhead(.class) and then decide at runtime if
the instance references other objects that should be sized (like key, value,
DiskId, etc.).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9517) Update all tests to use org.assertj.core.api.Assertions
[ https://issues.apache.org/jira/browse/GEODE-9517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9517: -- Labels: pull-request-available (was: ) > Update all tests to use org.assertj.core.api.Assertions > --- > > Key: GEODE-9517 > URL: https://issues.apache.org/jira/browse/GEODE-9517 > Project: Geode > Issue Type: Bug >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: pull-request-available > > Refactor all tests to use org.assertj.core.api.Assertions instead of all the > deprecated alternatives like assertTrue etc. > > This ticket will remain open till all the tests are refactored. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9801) CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are not accurate
[
https://issues.apache.org/jira/browse/GEODE-9801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9801:
Description:
This issue has been around since Geode 1.0.
CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
supposed to help geode users figure out how much memory is being used by
tombstones. But because of some over sites in the sizing code they actual
amount of memory used by tombstones is significantly higher. Some of the
mistakes made:
1. A Tombstone is added to a ConcurrentLinkedQueue. This is accounted for as a
single objRef. But each add to a ConcurrentLinkedQueue add a Node instance so
you have the object header size plus two objRefs.
2. The size of the RegionEntry is not accounted for. The size of the key in
this entry is but most of the memory used is in the RegionEntry fields itself.
And the key, in some cases, is stored inline in primitive fields in the
RegionEntry so Tombstone.getSize should not be asking the RegionEntry for its
key and then sizing it but should instead just ask the RegionEntry for its
memory footprint. It can then figure out if it needs to size any of the objects
it references (like the key).
3. the Tombstone class it self accounts for all its fields but forgot about its
own object header.
To fix this have the Tombstone class add the following:
{code:java}
private static final TOMBSTONE_OVERHEAD =
JvmSizeUtils.memoryOverhead(Tombstone.class);
{code}
For the Node overhead on ConcurrentLinkedQueue add this:
{code:java}
private static final NODE_OVERHEAD =
JvmSizeUtils.roundUpSize(JvmSizeUtils.getObjectHeaderSize() +
2*JvmSizeUtils.getReferenceSize());
{code}
For RegionEntry add a new "memoryOverhead" method on HashRegionEntry and then
implement it in all the many leaf classes. You can do this by modifying
LeafRegionEntry.cpp and running generateRegionEntryClasses.sh. You will want
each class to have a private static final field that calls
JvmSizeUtils.memoryOverhead(.class) and then decide at runtime if
the instance references other objects that should be sized (like key, value,
DiskId, etc.).
was:
This issue has been around since Geode 1.0.
CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
supposed to help geode users figure out how much memory is being used by
tombstones. But because of some over sites in the sizing code they actual
amount of memory used by tombstones is significantly higher. Some of the
mistakes made:
1. A Tombstone is added to a ConcurrentLinkedQueue. This is accounted for as a
single objRef. But each add to a ConcurrentLinkedQueue add a Node instance so
you have the object header size plus two objRefs.
2. The size of the RegionEntry is not accounted for. The size of the key in
this entry is but most of the memory used is in the RegionEntry fields itself.
And the key, in some cases, is stored inline in primitive fields in the
RegionEntry so Tombstone.getSize should not be asking the RegionEntry for its
key and then sizing it but should instead just ask the RegionEntry for its
memory footprint. It can then figure out if it needs to size any of the objects
it references (like the key).
3. the Tombstone class it self accounts for all its fields but forgot about its
own object header.
To fix this have the Tombstone class add the following:
{code:java}
private static final TOMBSTONE_OVERHEAD =
JvmSizeUtils.memoryOverhead(Tombstone.class);
{code}
For the Node overhead on ConcurrentLinkedQueue add this:
{code:java}
private static final NODE_OVERHEAD =
JvmSizeUtils.roundUpSize(JvmSizeUtils.getObjectHeaderSize() +
2*JvmSizeUtils.getReferenceSize());
{code}
For RegionEntry add a new "memoryOverhead" method on RegionEntry and then
implement it in all the many leaf classes. You can do this by modifying
LeafRegionEntry.cpp and running generateRegionEntryClasses.sh. You will want
each class to have a private static final field that calls
JvmSizeUtils.memoryOverhead(.class) and then decide at runtime if
the instance references other objects that should be sized (like key, value,
DiskId, etc.).
> CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
> not accurate
>
>
> Key: GEODE-9801
> URL: https://issues.apache.org/jira/browse/GEODE-9801
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.12.0
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This issue has been around since Geode 1.0.
> CachePerfStats.replicatedTombstonesSize and nonReplicatedTombstonesSize are
> supposed to help geode users figure out how much memory is being used by
> tombstones. But because of some over sites in the sizing code they
[jira] [Commented] (GEODE-8727) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated test[from_v1.2.0
[
https://issues.apache.org/jira/browse/GEODE-8727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439557#comment-17439557
]
Geode Integration commented on GEODE-8727:
--
Seen in [upgrade-test-openjdk8
#338|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/upgrade-test-openjdk8/builds/338]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0644/test-results/upgradeTest/1636128095/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0644/test-artifacts/1636128095/upgradetestfiles-openjdk8-1.15.0-build.0644.tgz].
> CI Failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
> test[from_v1.2.0
>
>
> Key: GEODE-8727
> URL: https://issues.apache.org/jira/browse/GEODE-8727
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Affects Versions: 1.14.0
>Reporter: Ray Ingles
>Priority: Major
> Labels: caching-applications
>
> This test hung in an upgradeTest run. Stack traces show it interacting with
> a Locator and making progress over the 15 seconds between traces.
> CI webpage:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/589
> Artifacts are here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0500/test-artifacts/1605733271/upgradetestfiles-OpenJDK11-1.14.0-build.0500.tgz
> Here is the main test thread:
> {code:java}
> "Test worker" #27 prio=5 os_prio=0 cpu=4900.15ms elapsed=2902.12s
> tid=0x7fe70cbd4800 nid=0x1b runnable [0x7fe6d8894000]
>java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(java.base@11.0.9.1/Native
> Method)
> at
> java.net.SocketInputStream.socketRead(java.base@11.0.9.1/SocketInputStream.java:115)
> at
> java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:168)
> at
> java.net.SocketInputStream.read(java.base@11.0.9.1/SocketInputStream.java:140)
> at
> java.io.BufferedInputStream.fill(java.base@11.0.9.1/BufferedInputStream.java:252)
> at
> java.io.BufferedInputStream.read(java.base@11.0.9.1/BufferedInputStream.java:271)
> - locked <0xf6487988> (a java.io.BufferedInputStream)
> at
> java.io.DataInputStream.readByte(java.base@11.0.9.1/DataInputStream.java:270)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(java.rmi@11.0.9.1/StreamRemoteCall.java:240)
> at
> sun.rmi.server.UnicastRef.invoke(java.rmi@11.0.9.1/UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(java.rmi@11.0.9.1/RemoteObjectInvocationHandler.java:217)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(java.rmi@11.0.9.1/RemoteObjectInvocationHandler.java:162)
> at com.sun.proxy.$Proxy53.executeMethodOnObject(Unknown Source)
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:620)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase.rollServerToCurrent(LuceneSearchWithRollingUpgradeTestBase.java:347)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeTestBase.rollServerToCurrentCreateLuceneIndexAndCreateRegion(LuceneSearchWithRollingUpgradeTestBase.java:359)
> at
> org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test(RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.java:108)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.9.1/Native
> Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.9.1/NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.9.1/DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(java.base@11.0.9.1/Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> {code}
--
This message
[jira] [Commented] (GEODE-8046) CI failure: ShowDeadlockDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17439558#comment-17439558 ] Geode Integration commented on GEODE-8046: -- Seen on support/1.13 in [distributed-test-openjdk8 #68|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/distributed-test-openjdk8/builds/68] ... see [test results|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0614/test-results/distributedTest/1636148304/] or download [artifacts|http://files.apachegeode-ci.info/builds/apache-support-1-13-main/1.13.5-build.0614/test-artifacts/1636148304/distributedtestfiles-openjdk8-1.13.5-build.0614.tgz]. > CI failure: ShowDeadlockDUnitTest > - > > Key: GEODE-8046 > URL: https://issues.apache.org/jira/browse/GEODE-8046 > Project: Geode > Issue Type: Bug >Reporter: Jianxia Chen >Priority: Major > Labels: ci-failure > > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/105 > org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest > > testDistributedDeadlockWithFunction FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$90/1594546850.run > in VM 1 running on Host f76e595f0aaa with 4 VMs > Caused by: > org.awaitility.core.ConditionTimeoutException: Condition with > org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase > was not fulfilled within 5 minutes. > org.apache.geode.management.internal.cli.commands.ShowDeadlockDUnitTest > > testNoDeadlock FAILED > org.apache.geode.test.dunit.RMIException: While invoking > org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase$$Lambda$90/1594546850.run > in VM 1 running on Host f76e595f0aaa with 4 VMs > Caused by: > org.awaitility.core.ConditionTimeoutException: Condition with > org.apache.geode.management.internal.cli.commands.ShowDeadlockDistributedTestBase > was not fulfilled within 5 minutes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
