[jira] [Commented] (GEODE-8412) s390x support for docker image
[ https://issues.apache.org/jira/browse/GEODE-8412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304114#comment-17304114 ] snehal commented on GEODE-8412: --- [~onichols] Thank you the details. > s390x support for docker image > -- > > Key: GEODE-8412 > URL: https://issues.apache.org/jira/browse/GEODE-8412 > Project: Geode > Issue Type: New Feature > Components: general >Reporter: snehal >Priority: Major > > Hi, > I am able to successfully build ApacheGeode image on s390x architecture using > [https://github.com/apache/geode/blob/develop/docker/Dockerfile] Dockerfile > without any modifications. > Is there any plan to support s390x docker image? > It would be nice to just pull s390x arch image from Dockerhub. > > Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9035) Enable all Hash tests in pipeline native-Redis tests
[ https://issues.apache.org/jira/browse/GEODE-9035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304191#comment-17304191 ] ASF subversion and git services commented on GEODE-9035: Commit fa6103b444d0357e5be34650df20acebdc7e2a7a in geode's branch refs/heads/develop from Ray Ingles [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fa6103b ] GEODE-9035: Enable Redis TCL tests for all Hash commands > Enable all Hash tests in pipeline native-Redis tests > > > Key: GEODE-9035 > URL: https://issues.apache.org/jira/browse/GEODE-9035 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Priority: Major > Labels: pull-request-available > > All hash commands are now supported in the compatibility-with-Redis > subsystem. This will enable the native Redis integration tests (written in > TCL) to run the Hash test suite against Geode compatibility-with-Redis. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Ingles updated GEODE-9037: -- Labels: blocks-1.14.0 (was: ) > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0 > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raymond Ingles reassigned GEODE-9037: - Assignee: Raymond Ingles > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9026) Fix race-condition for RegisterAllWithConsistencyDisabled IT
[ https://issues.apache.org/jira/browse/GEODE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304233#comment-17304233 ] ASF subversion and git services commented on GEODE-9026: Commit f03b5dac93d25dc2f488eb9a5bba63f41a999092 in geode-native's branch refs/heads/develop from Mario Salazar de Torres [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=f03b5da ] GEODE-9026: Fix race cond in RegisterKeysTest #2 (#769) - As it seems there is still a very rare race condition that might cause the test to fail. - If the listener is called before wait_for is called, the test fails due to timeout. - A flag and predicate has been added to tackle this race condition. > Fix race-condition for RegisterAllWithConsistencyDisabled IT > > > Key: GEODE-9026 > URL: https://issues.apache.org/jira/browse/GEODE-9026 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > There is a race condition in this test having to do with GMock's expectances > being set after the call happens. This can be solved as easily as setting the > expectance sooner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9026) Fix race-condition for RegisterAllWithConsistencyDisabled IT
[ https://issues.apache.org/jira/browse/GEODE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304234#comment-17304234 ] ASF GitHub Bot commented on GEODE-9026: --- pdxcodemonkey merged pull request #769: URL: https://github.com/apache/geode-native/pull/769 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix race-condition for RegisterAllWithConsistencyDisabled IT > > > Key: GEODE-9026 > URL: https://issues.apache.org/jira/browse/GEODE-9026 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > There is a race condition in this test having to do with GMock's expectances > being set after the call happens. This can be solved as easily as setting the > expectance sooner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8442) Exception in server not identified correctly in client
[
https://issues.apache.org/jira/browse/GEODE-8442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304237#comment-17304237
]
ASF GitHub Bot commented on GEODE-8442:
---
pdxcodemonkey commented on pull request #713:
URL: https://github.com/apache/geode-native/pull/713#issuecomment-802041816
@gaussianrecurrence I believe this one is ready to be rebased onto develop
now so that CI will run and (hopefully) pass.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Exception in server not identified correctly in client
> --
>
> Key: GEODE-8442
> URL: https://issues.apache.org/jira/browse/GEODE-8442
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Alberto Bustamante Reyes
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> Native client is not identifying correctly an exception returned by the
> server.
> This is a log from an exception properly identified (I have introduced ""
> where I think I have to hide sensitive information):
> {code}
> [error 2020/07/22 09:17:10.831337 UTC ]
> CacheTransactionManager::failover: An exception
> (org.apache.geode.cache.TransactionDataNodeHasDepartedException: Could not
> find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> at
> org.apache.geode.internal.cache.tier.sockets.command.TXFailoverCommand.cmdExecute(TXFailoverCommand.java:126)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ) happened at remote server.
> data-access: write_element:[TransactionDataNodeHasDepartedException]
> .get()::apache::geode::client::TransactionDataNodeHasDepartedException:org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Could not find transaction host for TXId:
> (default_GeodeDS:1:loner):3:Native_gdbdedfebe1:default_GeodeDS:6022
> {code}
> But in this case, although the exception received is also a
> TransactionDataNodeHasDepartedException, it is "translated" to an Unknown
> exception:
> {code}
> [error 2020/07/22 09:17:10.979506 UTC ] Region::containsKeyOnServer:: An
> exception (org.apache.geode.cache.TransactionDataNodeHasDepartedException:
> Transaction data node 192.168.240.13(dms-server-1:1):41000 has departed.
> To proceed, rollback this transaction and begin a new one., caused by
> org.apache.geode.internal.cache.ForceReattemptException: PartitionResponse
> got remote CacheClosedException
> at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.containsKey(PartitionedTXRegionStub.java:247)
> at
> org.apache.geode.internal.cache.TXStateStub.containsKey(TXStateStub.java:431)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.containsKey(TXStateProxyImpl.java:530)
> at
> org.apache.geode.internal.cache.PartitionedRegion.containsKey(PartitionedRegion.java:6402)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ContainsKey66.cmdExecute(ContainsKey66.java:138)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:177)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
> at
> org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPool
[jira] [Resolved] (GEODE-9026) Fix race-condition for RegisterAllWithConsistencyDisabled IT
[ https://issues.apache.org/jira/browse/GEODE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres resolved GEODE-9026. Resolution: Fixed > Fix race-condition for RegisterAllWithConsistencyDisabled IT > > > Key: GEODE-9026 > URL: https://issues.apache.org/jira/browse/GEODE-9026 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > There is a race condition in this test having to do with GMock's expectances > being set after the call happens. This can be solved as easily as setting the > expectance sooner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-9026) Fix race-condition for RegisterAllWithConsistencyDisabled IT
[ https://issues.apache.org/jira/browse/GEODE-9026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Salazar de Torres closed GEODE-9026. -- > Fix race-condition for RegisterAllWithConsistencyDisabled IT > > > Key: GEODE-9026 > URL: https://issues.apache.org/jira/browse/GEODE-9026 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.13.1 >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > There is a race condition in this test having to do with GMock's expectances > being set after the call happens. This can be solved as easily as setting the > expectance sooner. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304241#comment-17304241 ] Donal Evans commented on GEODE-8950: Bisecting to determine when this degradation was introduced continues, data and analysis are available in the spreadsheet linked above: [https://docs.google.com/spreadsheets/d/1jTPiWMF1L1ItrQBMokXqhD4veMIryhiNSLxw36XegqQ/edit?usp=sharing] > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8860) Performance degradation in 1.13.0 gets and getAll
[ https://issues.apache.org/jira/browse/GEODE-8860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304244#comment-17304244 ] Donal Evans commented on GEODE-8860: This blocker is still being investigated. > Performance degradation in 1.13.0 gets and getAll > - > > Key: GEODE-8860 > URL: https://issues.apache.org/jira/browse/GEODE-8860 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.0 >Reporter: Hale Bales >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0 > > A performance degradation has been measured in Geode 1.13.0. The gets and > getAlls show a decrease in performance >5%. Find the build and/or commit > where the degradation occurred and track down the cause. This will require > access to dedicated hardware for performance testing as well as experience > with YourKit. You may also need VSD. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9040) The SingleThreadColocationLogger executorService is not shutdown when the server is stopped
[
https://issues.apache.org/jira/browse/GEODE-9040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304270#comment-17304270
]
ASF subversion and git services commented on GEODE-9040:
Commit 3b422bbe9631b7531633671a3938ed9600cfbc6e in geode's branch
refs/heads/develop from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b422bb ]
GEODE-9040: Shutdown ExecutorService when the SingleThreadColocationLogger is
stopped
> The SingleThreadColocationLogger executorService is not shutdown when the
> server is stopped
> ---
>
> Key: GEODE-9040
> URL: https://issues.apache.org/jira/browse/GEODE-9040
> Project: Geode
> Issue Type: Bug
> Components: logging
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: pull-request-available
>
> When a server is shutdown, its JVM remains alive because the ExecutorService
> created by the SingleThreadColocationLogger is not terminated nor is its
> thread a daemon:
> {noformat}
> "ColocationLogger for customer" #57 prio=5 os_prio=31 tid=0x7fb39d4e4000
> nid=0xb203 waiting on condition [0x7dc58000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000785268818> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The SingleThreadColocationLogger only gets created when there are missing
> co-located regions.
> We can either terminate the ExecutorService or make its thread a daemon or
> both.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9032) Redis: SLOWLOG command supported
[ https://issues.apache.org/jira/browse/GEODE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hale Bales resolved GEODE-9032. --- Fix Version/s: 1.14.0 Resolution: Fixed > Redis: SLOWLOG command supported > > > Key: GEODE-9032 > URL: https://issues.apache.org/jira/browse/GEODE-9032 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > To support the DataDog dashboard out-of-the-box, we need to support a dummy > implementation of the SLOWLOG command. It does not need to support returning > any actual SLOWLOG entries. > A.C. > Unit/integration tests for both Geode and native Redis passing > README/redis_api_for_geode.html.md.erb updated to make command > "supported" (noting limitations!) > or > Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9032) Redis: SLOWLOG command supported
[ https://issues.apache.org/jira/browse/GEODE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304274#comment-17304274 ] ASF subversion and git services commented on GEODE-9032: Commit 05989e5b5368e5d8230b9b7ca5b600a729d2f73e in geode's branch refs/heads/support/1.14 from Hale Bales [ https://gitbox.apache.org/repos/asf?p=geode.git;h=05989e5 ] GEODE-9032: support SLOWLOG command (#6131) (#6149) - update documentation to show SLOWLOG as a supported command - move SLOWLOG to supported commands list in RedisCommandTypes - update supported commands test - did not add any new tests because it was already very well tested. - add footnote to readme (cherry picked from commit dfc16562a1965d4d0bc32756bdf2a9664b4127c2) > Redis: SLOWLOG command supported > > > Key: GEODE-9032 > URL: https://issues.apache.org/jira/browse/GEODE-9032 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0 > > > To support the DataDog dashboard out-of-the-box, we need to support a dummy > implementation of the SLOWLOG command. It does not need to support returning > any actual SLOWLOG entries. > A.C. > Unit/integration tests for both Geode and native Redis passing > README/redis_api_for_geode.html.md.erb updated to make command > "supported" (noting limitations!) > or > Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8968) PdxTypeRegistry clean up causes a coredump
[ https://issues.apache.org/jira/browse/GEODE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304302#comment-17304302 ] ASF GitHub Bot commented on GEODE-8968: --- gaussianrecurrence opened a new pull request #770: URL: https://github.com/apache/geode-native/pull/770 - In those scenarios in which Pdx serialization occurs while PdxTypeRegistry is being cleaned up, it happened that NC crashed because it couldn't find the PdxType. - This commit adds retries to Pdx serialization, and in case retries are exhausted, UnknownPdxTypeException is thrown, so it can be handled by the user. - Implemented IT to verify this behaviour. - TODO. Enable IT when PR #715 gets merged. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > PdxTypeRegistry clean up causes a coredump > -- > > Key: GEODE-8968 > URL: https://issues.apache.org/jira/browse/GEODE-8968 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.14.0 >Reporter: Mario Salazar de Torres >Priority: Major > > *GIVEN* a client/server that with PDX serialization > *WHEN* the client looses connection towards the cluster > *AND* PdxTypeRegistry is cleaned up > *WHILE* a PDX instance is being serialized > *THEN* a coredump occurs > > *Additional information:* > As it seems PdxHelper::serializePdx calls toData -> toDataMutable -> > getPdxType and the later part returns a nullptr if the registry was cleaned > up in the process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8968) PdxTypeRegistry clean up causes a coredump
[ https://issues.apache.org/jira/browse/GEODE-8968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-8968: -- Labels: pull-request-available (was: ) > PdxTypeRegistry clean up causes a coredump > -- > > Key: GEODE-8968 > URL: https://issues.apache.org/jira/browse/GEODE-8968 > Project: Geode > Issue Type: Bug > Components: native client >Affects Versions: 1.14.0 >Reporter: Mario Salazar de Torres >Priority: Major > Labels: pull-request-available > > *GIVEN* a client/server that with PDX serialization > *WHEN* the client looses connection towards the cluster > *AND* PdxTypeRegistry is cleaned up > *WHILE* a PDX instance is being serialized > *THEN* a coredump occurs > > *Additional information:* > As it seems PdxHelper::serializePdx calls toData -> toDataMutable -> > getPdxType and the later part returns a nullptr if the registry was cleaned > up in the process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6257) Move ThinClientPoolTestsN to New Test Framework
[ https://issues.apache.org/jira/browse/GEODE-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-6257. --- > Move ThinClientPoolTestsN to New Test Framework > --- > > Key: GEODE-6257 > URL: https://issues.apache.org/jira/browse/GEODE-6257 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > > Moving to Visual Studio 2017 appears to reveal this test to be FLAKY. > Although the Debug build passes in the CI (although takes several retries), > the Release build isn't passing using the default retries. Also, this test > only fails in the CI. I have been unable to make it fail locally on the new > iMac Pro. > For now this test has been marked as FLAKY to allow for a green CI in the VS > 2017 build. It should be moved to the new framework to debug it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6257) Move ThinClientPoolTestsN to New Test Framework
[ https://issues.apache.org/jira/browse/GEODE-6257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-6257. - Resolution: Won't Fix > Move ThinClientPoolTestsN to New Test Framework > --- > > Key: GEODE-6257 > URL: https://issues.apache.org/jira/browse/GEODE-6257 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > > Moving to Visual Studio 2017 appears to reveal this test to be FLAKY. > Although the Debug build passes in the CI (although takes several retries), > the Release build isn't passing using the default retries. Also, this test > only fails in the CI. I have been unable to make it fail locally on the new > iMac Pro. > For now this test has been marked as FLAKY to allow for a green CI in the VS > 2017 build. It should be moved to the new framework to debug it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7710) CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest fails intermittently because one locator is missing the LockServiceMXBean
[
https://issues.apache.org/jira/browse/GEODE-7710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304311#comment-17304311
]
Geode Integration commented on GEODE-7710:
--
Seen in [DistributedTestOpenJDK8
#83|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/83]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0064/test-results/distributedTest/1616088513/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0064/test-artifacts/1616088513/distributedtestfiles-OpenJDK8-1.15.0-build.0064.tgz].
> CI Failure: JMXMBeanReconnectDUnitTest aka JmxServerReconnectDistributedTest
> fails intermittently because one locator is missing the LockServiceMXBean
> --
>
> Key: GEODE-7710
> URL: https://issues.apache.org/jira/browse/GEODE-7710
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: GeodeOperationAPI, flaky, pull-request-available
> Time Spent: 5h
> Remaining Estimate: 0h
>
> Multiple tests in JMXMBeanReconnectDUnitTest may fail an await due to one of
> the locators missing the LockServiceMXBean for the cluster config service.
> {noformat}
> but could not find:
>
> <[GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator1]>
> {noformat}
> These test failures are caused by *GEODE-7739*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9043) A register interest attempt from a newer client to an older server throws a NoSubscriptionServersAvailableException instead of a ServerRefusedConnectionException
[
https://issues.apache.org/jira/browse/GEODE-9043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sarah Abbey updated GEODE-9043:
---
Priority: Minor (was: Major)
> A register interest attempt from a newer client to an older server throws a
> NoSubscriptionServersAvailableException instead of a
> ServerRefusedConnectionException
> -
>
> Key: GEODE-9043
> URL: https://issues.apache.org/jira/browse/GEODE-9043
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Barrett Oglesby
>Assignee: Sarah Abbey
>Priority: Minor
> Labels: pull-request-available
>
> The exception in the register interest case is a bit confusing.
> If a 1.13.2 client attempts to connect to a 1.13.0 server and do a put, it
> throws this ServerRefusedConnectionException with the exact cause:
> {noformat}
> Exception in thread "main"
> org.apache.geode.cache.client.NoAvailableServersException:
> org.apache.geode.cache.client.ServerRefusedConnectionException:
> nn.nnn.nnn.nn(3047):41001(version:GEODE 1.13.0) refused connection: Peer
> or client version with ordinal 121 not supported. Highest known version is
> 1.13.0 Client: /nn.nnn.nnn.nn:64123.
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.createPooledConnection(ConnectionManagerImpl.java:200)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:273)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:796)
> at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:91)
> {noformat}
> If the client attempts to registerInterest, it throws this
> NoSubscriptionServersAvailableException:
> {noformat}
> Exception in thread "main"
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:190)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:432)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:870)
> at
> org.apache.geode.cache.Region.registerInterestForAllKeys(Region.java:1657)
> {noformat}
> The log does contain a message like below so it can be determined the exact
> cause, but not in the exception:
> {noformat}
> [warn 2021/03/15 11:59:04.100 PDT client tid=0x1] Could not create a
> new connection to server: nn.nnn.nnn.nn(9838):41001(version:GEODE 1.13.0)
> refused connection: Peer or client version with ordinal 121 not supported.
> Highest known version is 1.13.0 Client: /nn.nnn.nnn.nn:65323.
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-6452) Create a new cpp ssl test using new test framework
[ https://issues.apache.org/jira/browse/GEODE-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-6452. - Resolution: Won't Fix > Create a new cpp ssl test using new test framework > -- > > Key: GEODE-6452 > URL: https://issues.apache.org/jira/browse/GEODE-6452 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > > We need a new test that will make it easier to debug our current failing cpp > ssl example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6452) Create a new cpp ssl test using new test framework
[ https://issues.apache.org/jira/browse/GEODE-6452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-6452. --- > Create a new cpp ssl test using new test framework > -- > > Key: GEODE-6452 > URL: https://issues.apache.org/jira/browse/GEODE-6452 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > > We need a new test that will make it easier to debug our current failing cpp > ssl example. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-5625) CI Failure: RollingUpgradeRollServersOnPartitionedRegion_dataserializable
[
https://issues.apache.org/jira/browse/GEODE-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304338#comment-17304338
]
Geode Integration commented on GEODE-5625:
--
Seen in [UpgradeTestOpenJDK11
#78|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK11/builds/78]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0065/test-results/upgradeTest/1616091109/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0065/test-artifacts/1616091109/upgradetestfiles-OpenJDK11-1.15.0-build.0065.tgz].
> CI Failure: RollingUpgradeRollServersOnPartitionedRegion_dataserializable
> -
>
> Key: GEODE-5625
> URL: https://issues.apache.org/jira/browse/GEODE-5625
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Sai Boorlagadda
>Priority: Major
> Labels: swat
>
> [https://concourse.apachegeode-ci.info/builds/19873]
> Build artifacts:
> [http://files.apachegeode-ci.info/builds/geode-pr-2357/test-results/upgradeTest/1534894392/]
>
> {code:java}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnPartitionedRegion_dataserializable
> > testRollServersOnPartitionedRegion_dataserializable[from_v120] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 6207
> [fatal 2018/08/21 23:09:52.169 UTC
> tid=225] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> ---
> Found suspect string in log4j at line 6222
> [fatal 2018/08/21 23:09:53.171 UTC
> tid=225] Membership service failure: Exiting due to possible network
> partition event due to loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> org.apache.geode.ForcedDisconnectException: Exiting due to possible
> network partition event due to loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2534)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1054)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1500(GMSJoinLeave.java:92)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2507)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2136)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2214){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-6632) Add an option to allow developers to skip tests with a command line option
[
https://issues.apache.org/jira/browse/GEODE-6632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ernest Burghardt updated GEODE-6632:
Priority: Minor (was: Major)
> Add an option to allow developers to skip tests with a command line option
> --
>
> Key: GEODE-6632
> URL: https://issues.apache.org/jira/browse/GEODE-6632
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Charlie Black
>Priority: Minor
>
> Add an option to allow developers to skip tests with a command line option
> {{cmake . -DSKIP_INTEGRATION_TESTS=true -DSKIP_UNIT_TESTS=FALSE}}
> This would allow community members that are looking to contribute something
> other than code easier access to the binaries.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-6844) Move private implementation into source files.
[ https://issues.apache.org/jira/browse/GEODE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-6844. --- > Move private implementation into source files. > -- > > Key: GEODE-6844 > URL: https://issues.apache.org/jira/browse/GEODE-6844 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Time Spent: 6h > Remaining Estimate: 0h > > Function and method definitions across all header files within the > "cppcache/src" directory are to be moved into their corresponding source > files, source files created as necessary. "inline" and "explicit" are to be > removed. Redundant "virtual" and "final" are to be removed. Derived > destructors are to be marked override. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6844) Move private implementation into source files.
[ https://issues.apache.org/jira/browse/GEODE-6844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-6844. - Resolution: Won't Fix let's replace with specific tickets... > Move private implementation into source files. > -- > > Key: GEODE-6844 > URL: https://issues.apache.org/jira/browse/GEODE-6844 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Matthew Reddington >Priority: Major > Time Spent: 6h > Remaining Estimate: 0h > > Function and method definitions across all header files within the > "cppcache/src" directory are to be moved into their corresponding source > files, source files created as necessary. "inline" and "explicit" are to be > removed. Redundant "virtual" and "final" are to be removed. Derived > destructors are to be marked override. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7145) Geode native client PDX deadlock when not reading all data
[ https://issues.apache.org/jira/browse/GEODE-7145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304362#comment-17304362 ] Ernest Burghardt commented on GEODE-7145: - Hello [~mivanac] this was filed as an Improvement or feature request... I ask wondering if there is a Bug here or is Geode just not operating as you expect/desire ? > Geode native client PDX deadlock when not reading all data > -- > > Key: GEODE-7145 > URL: https://issues.apache.org/jira/browse/GEODE-7145 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Ivanac >Priority: Major > Attachments: pdx_deadlock.tgz > > > A plausible thread deadlock in geode-native C++ library (versions 1.8 and > 1.9) has been found. It seems to happen in the following circumstances: > * A reader program continuously reads objects in a region, objects > deserialized with PDX. > * The reader program is NOT consuming all fields in the objects, so some > information is left in the cache. > * PdxIgnoreUnreadFields is set to FALSE. > > With previous setup, it has been observed that after around 20 seconds of > first object read, the reader program gets stuck. > > A program source that reproduces the problem is attached (pdx_deadlock.tgz). > This program is based on geode’s native example > (geode-native/examples/cpp/pdxserializable/) with some minor modifications. > > Procedure > # Build pdx_deadlock program using cmake and copy binary to test machine. > # Use gfsh to create region with command: create region > --name="custom_orders" --type=PARTITION > # Execute pdx_deadlock once in create mode to add just one order entry in > region: ./pdx_deadlock create > # Execute pdx_deadlock in read loop mode with command: ./pdx_deadlock > > # Check in output the order object is being read. In less than 30 seconds > the deadlock shall happen, and iteration loop will not finish. > > Additionally, if program is executed with these arguments: > ./pdx_deadlock ignore-unread-fields > It will set geode client cache factory configuration value > PdxIgnoreUnreadFields to TRUE, and NO deadlock would occur, and the program > will finish all iterations. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304364#comment-17304364 ] ASF subversion and git services commented on GEODE-8946: Commit 0870d5dc2fd769d51f63ec7e0d64c9c8cb4d2c8f in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0870d5d ] GEODE-8946: User Guide - add an Upgrade section (#6134) * GEODE-8946: User Guide - add an Upgrade section > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304365#comment-17304365 ] ASF subversion and git services commented on GEODE-8946: Commit 0870d5dc2fd769d51f63ec7e0d64c9c8cb4d2c8f in geode's branch refs/heads/develop from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0870d5d ] GEODE-8946: User Guide - add an Upgrade section (#6134) * GEODE-8946: User Guide - add an Upgrade section > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7236) Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings
[ https://issues.apache.org/jira/browse/GEODE-7236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304368#comment-17304368 ] Ernest Burghardt commented on GEODE-7236: - [~bbender] what is left to do on this? > Fix Clang 'defaulted-function-deleted' and 'c++2a-compat' warnings > -- > > Key: GEODE-7236 > URL: https://issues.apache.org/jira/browse/GEODE-7236 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > > Repro steps: > * Sync up to geode native `develop` branch on a Mac with latest Clang `Apple > clang version 11.0.0 (clang-1100.0.33.8)` > * Check top-level CMakeLists.txt and make sure these warnings are enabled, > i.e. not turned off in `target_compile_options(_WarningsAsError INTERFACE` > * Configure and build Geode Native > Expected Result: > * Geode Native builds to completion > Actual Result: > * Clang warns about these things, and the build fails due to WarningsAsError. > These warnings have been disabled (GEODE-7325) to get the build back off the > floor, but we need to provide the actual code fix and re-enable the warnings. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9032) Redis: SLOWLOG command supported
[ https://issues.apache.org/jira/browse/GEODE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9032: Fix Version/s: 1.15.0 > Redis: SLOWLOG command supported > > > Key: GEODE-9032 > URL: https://issues.apache.org/jira/browse/GEODE-9032 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0, 1.15.0 > > > To support the DataDog dashboard out-of-the-box, we need to support a dummy > implementation of the SLOWLOG command. It does not need to support returning > any actual SLOWLOG entries. > A.C. > Unit/integration tests for both Geode and native Redis passing > README/redis_api_for_geode.html.md.erb updated to make command > "supported" (noting limitations!) > or > Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9032) Redis: SLOWLOG command supported
[ https://issues.apache.org/jira/browse/GEODE-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-9032: Labels: blocks-1.14.0 pull-request-available (was: pull-request-available) > Redis: SLOWLOG command supported > > > Key: GEODE-9032 > URL: https://issues.apache.org/jira/browse/GEODE-9032 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Hale Bales >Assignee: Hale Bales >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > To support the DataDog dashboard out-of-the-box, we need to support a dummy > implementation of the SLOWLOG command. It does not need to support returning > any actual SLOWLOG entries. > A.C. > Unit/integration tests for both Geode and native Redis passing > README/redis_api_for_geode.html.md.erb updated to make command > "supported" (noting limitations!) > or > Stories in the backlog to fix the identified issues (with JIRA tickets) > and problem tests ignored -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7324) FIx invalid encoding in log files
[ https://issues.apache.org/jira/browse/GEODE-7324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304369#comment-17304369 ] Ernest Burghardt commented on GEODE-7324: - [~bbender] sounds like `gnmsg` related - is this still as issue? > FIx invalid encoding in log files > - > > Key: GEODE-7324 > URL: https://issues.apache.org/jira/browse/GEODE-7324 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > > As a developer, I wish to be able to write log parsing utilities for the > native client if need be. To do this, I need to be able to read the text in > the log files via standard languages like Python, C#, etc. Unfortunately, > recent changes to some log statements in the native client code will cause > invalid utf-8 bytes to be written to the log in some circumstances, making > reading the log very difficult. > > repro steps: > i. Enable debug-level logging in NC integration tests, and set log-file to a > known filename > ii. Run a test case, to generate the log file > iii. Attempt to parse the file as utf-8 in Python > > Expected result: > * File parses correctly > Actual result: > * Python throws an exception, saying it has encountered an invalid start byte > > This is known to happen when using the '%zu' format specifier to log a value > of type std::chrono::Rep on MacOS. Other compilers/OSes/types may or may not > display this behavior. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304379#comment-17304379 ] ASF subversion and git services commented on GEODE-8946: Commit c661e2c4b437bb7514772cb57ca495f6527612b9 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c661e2c ] GEODE-8946: User Guide - add an Upgrade section (#6134) * GEODE-8946: User Guide - add an Upgrade section > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304378#comment-17304378 ] ASF subversion and git services commented on GEODE-8946: Commit c661e2c4b437bb7514772cb57ca495f6527612b9 in geode's branch refs/heads/support/1.14 from Dave Barnes [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c661e2c ] GEODE-8946: User Guide - add an Upgrade section (#6134) * GEODE-8946: User Guide - add an Upgrade section > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304383#comment-17304383 ] Dave Barnes commented on GEODE-8946: Merged to develop (1.15) and cherry-picked to the support/1.14 branch for inclusion in the upcoming release candidate. > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8946) User Guide - add an Upgrade section
[ https://issues.apache.org/jira/browse/GEODE-8946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes resolved GEODE-8946. Fix Version/s: 1.15.0 1.14.0 Resolution: Fixed > User Guide - add an Upgrade section > --- > > Key: GEODE-8946 > URL: https://issues.apache.org/jira/browse/GEODE-8946 > Project: Geode > Issue Type: New Feature > Components: docs >Affects Versions: 1.13.1 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.14.0, 1.15.0 > > > The Geode user guide describes installation, but does not describe how to > upgrade from an older version. As Geode is now in its 13th release, it is > time to address the upgrade issue. As community member > [~alberto.bustamante.reyes] points out: > "Upgrade info is something that a Geode user should expect to find in the > user guide." > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7324) FIx invalid encoding in log files
[ https://issues.apache.org/jira/browse/GEODE-7324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304385#comment-17304385 ] Blake Bender commented on GEODE-7324: - No, there was a specific log statement involved here, and I think it ended up causing another problem that I had to fix on another ticket. At any rate I know it's fixed, and I'm unaware of any current issues with strings in log files. > FIx invalid encoding in log files > - > > Key: GEODE-7324 > URL: https://issues.apache.org/jira/browse/GEODE-7324 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > > As a developer, I wish to be able to write log parsing utilities for the > native client if need be. To do this, I need to be able to read the text in > the log files via standard languages like Python, C#, etc. Unfortunately, > recent changes to some log statements in the native client code will cause > invalid utf-8 bytes to be written to the log in some circumstances, making > reading the log very difficult. > > repro steps: > i. Enable debug-level logging in NC integration tests, and set log-file to a > known filename > ii. Run a test case, to generate the log file > iii. Attempt to parse the file as utf-8 in Python > > Expected result: > * File parses correctly > Actual result: > * Python throws an exception, saying it has encountered an invalid start byte > > This is known to happen when using the '%zu' format specifier to log a value > of type std::chrono::Rep on MacOS. Other compilers/OSes/types may or may not > display this behavior. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7217) Provide cmake switches to build static/shared libs, tests
[ https://issues.apache.org/jira/browse/GEODE-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-7217. - Resolution: Won't Fix > Provide cmake switches to build static/shared libs, tests > - > > Key: GEODE-7217 > URL: https://issues.apache.org/jira/browse/GEODE-7217 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > As a developer, I would like to minimize the time I spend waiting for builds. > A good portion of the time, the only things I wish to build in the native > client tree are either the static or shared libraries, and sometimes I don't > wish to build tests. All three of these should be switchable via cmake > variables. > > Acceptance criteria: > * Given a clean native client build tree > * When I specify BUILD_STATIC:BOOL=NO, or BUILD_SHARED:BOOL=NO, or > BUILD_TESTS:BOOL=NO > * Then the corresponding components should not be built in the tree -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7217) Provide cmake switches to build static/shared libs, tests
[ https://issues.apache.org/jira/browse/GEODE-7217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-7217. --- > Provide cmake switches to build static/shared libs, tests > - > > Key: GEODE-7217 > URL: https://issues.apache.org/jira/browse/GEODE-7217 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > As a developer, I would like to minimize the time I spend waiting for builds. > A good portion of the time, the only things I wish to build in the native > client tree are either the static or shared libraries, and sometimes I don't > wish to build tests. All three of these should be switchable via cmake > variables. > > Acceptance criteria: > * Given a clean native client build tree > * When I specify BUILD_STATIC:BOOL=NO, or BUILD_SHARED:BOOL=NO, or > BUILD_TESTS:BOOL=NO > * Then the corresponding components should not be built in the tree -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8510) Write Testing.md to Illustrate How to Contribute New Tests
[ https://issues.apache.org/jira/browse/GEODE-8510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-8510: Component/s: docs > Write Testing.md to Illustrate How to Contribute New Tests > -- > > Key: GEODE-8510 > URL: https://issues.apache.org/jira/browse/GEODE-8510 > Project: Geode > Issue Type: Improvement > Components: docs, native client >Reporter: Michael Martell >Priority: Major > > Testing for geode-native consists of a lot of different testing environments > including NUnit, GoogleTest, XUnit, as well as legacy tests that use our own > built-in test frameworks. We need a document describing the methodology for > writing new tests using our new frameworks for C++ and .NET. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8208) Remove global initLib/closeLib methods from CppCacheLibrary
[ https://issues.apache.org/jira/browse/GEODE-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt updated GEODE-8208: Issue Type: Improvement (was: Task) > Remove global initLib/closeLib methods from CppCacheLibrary > --- > > Key: GEODE-8208 > URL: https://issues.apache.org/jira/browse/GEODE-8208 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > closeLib contains no code, just remove it. initLib is only one line of code, > a call to ACE::init(). If there is to be any global initialization code for > geode-native, and it currently doesn't appear that there is, it needs to be > exposed in the public API and called explicitly by the application, where > object lifetimes etc are known. Since CppCacheLibrary isn't public, and once > we remove ACE (GEODE-2484) there will literally be no code in either of these > methods, we should delete them and move on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8208) Remove global initLib/closeLib methods from CppCacheLibrary
[ https://issues.apache.org/jira/browse/GEODE-8208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304435#comment-17304435 ] Ernest Burghardt commented on GEODE-8208: - [~bbender] could we block this on GEODE-2484? if not another ticket perhaps > Remove global initLib/closeLib methods from CppCacheLibrary > --- > > Key: GEODE-8208 > URL: https://issues.apache.org/jira/browse/GEODE-8208 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Blake Bender >Priority: Major > > closeLib contains no code, just remove it. initLib is only one line of code, > a call to ACE::init(). If there is to be any global initialization code for > geode-native, and it currently doesn't appear that there is, it needs to be > exposed in the public API and called explicitly by the application, where > object lifetimes etc are known. Since CppCacheLibrary isn't public, and once > we remove ACE (GEODE-2484) there will literally be no code in either of these > methods, we should delete them and move on. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"
[
https://issues.apache.org/jira/browse/GEODE-8616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304442#comment-17304442
]
Geode Integration commented on GEODE-8616:
--
Seen in [DistributedTestOpenJDK8
#83.1|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/83.1]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0064/test-results/distributedTest/1616097858/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0064/test-artifacts/1616097858/distributedtestfiles-OpenJDK8-1.15.0-build.0064.tgz].
> ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected
> socket timed out on client"
> --
>
> Key: GEODE-8616
> URL: https://issues.apache.org/jira/browse/GEODE-8616
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.12.1
>Reporter: Donal Evans
>Priority: Major
> Labels: flaky-test
>
> {noformat}
> > Task :geode-core:distributedTest
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest >
> largeObjectPutWithReadTimeoutThrowsException FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
> in VM 2 running on Host c1346ab7b3e3 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)
> Caused by:
> org.apache.geode.cache.client.ServerConnectivityException: Pool
> unexpected socket timed out on client connection=Pooled Connection to
> c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not
> connect after 1 attempts
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
> at
> org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
> at
> org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
> at
> org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
> at
> org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
> at
> org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz
> This is a flaky failure.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-8322) Utilize Boost Library Instead of Platform Dependent Test Code
[ https://issues.apache.org/jira/browse/GEODE-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt closed GEODE-8322. --- > Utilize Boost Library Instead of Platform Dependent Test Code > - > > Key: GEODE-8322 > URL: https://issues.apache.org/jira/browse/GEODE-8322 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > > The new SNITest.cpp file utilizes #ifdef PLATFORM to launch docker components > and also for retrieving the working directory. Although only test code, we > should endeavor to leverage standard libraries for all new development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8322) Utilize Boost Library Instead of Platform Dependent Test Code
[ https://issues.apache.org/jira/browse/GEODE-8322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Burghardt resolved GEODE-8322. - Resolution: Fixed > Utilize Boost Library Instead of Platform Dependent Test Code > - > > Key: GEODE-8322 > URL: https://issues.apache.org/jira/browse/GEODE-8322 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Michael Martell >Priority: Major > > The new SNITest.cpp file utilizes #ifdef PLATFORM to launch docker components > and also for retrieving the working directory. Although only test code, we > should endeavor to leverage standard libraries for all new development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9047) Refactor mangement.internal.cli.result package in geode-gfsh
[ https://issues.apache.org/jira/browse/GEODE-9047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund reassigned GEODE-9047: Assignee: Kirk Lund > Refactor mangement.internal.cli.result package in geode-gfsh > > > Key: GEODE-9047 > URL: https://issues.apache.org/jira/browse/GEODE-9047 > Project: Geode > Issue Type: Wish > Components: gfsh >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > > Refactor mangement.internal.cli.result package in geode-gfsh. Some of the > issues to cleanup are: > * too many inner classes that are public and used outside the package > * most classes do not have unit tests > * CommandResultException is serializable but has a non-serializable, > non-transient field -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9047) Refactor mangement.internal.cli.result package in geode-gfsh
Kirk Lund created GEODE-9047: Summary: Refactor mangement.internal.cli.result package in geode-gfsh Key: GEODE-9047 URL: https://issues.apache.org/jira/browse/GEODE-9047 Project: Geode Issue Type: Wish Components: gfsh Reporter: Kirk Lund Refactor mangement.internal.cli.result package in geode-gfsh. Some of the issues to cleanup are: * too many inner classes that are public and used outside the package * most classes do not have unit tests * CommandResultException is serializable but has a non-serializable, non-transient field -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9048) Remove the timeout on DockerizedExecHandle startup
[
https://issues.apache.org/jira/browse/GEODE-9048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dale Emery reassigned GEODE-9048:
-
Assignee: Dale Emery
> Remove the timeout on DockerizedExecHandle startup
> --
>
> Key: GEODE-9048
> URL: https://issues.apache.org/jira/browse/GEODE-9048
> Project: Geode
> Issue Type: Test
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>
> In the Dockerized test plugin, {{DockerizedExecHandle.start()}} throws a
> timeout exception if the process does not start within 30 seconds. The error
> handling code tries to abort the process, gets confused because the process
> has not started, and throws an {{IllegalStateException}}, preventing Gradle
> from reporting the original timeout exception.
> {{DockerizedExecHandle.start()}} is a modified copy of the code from Gradle's
> {{DefaultExecHandle}}. Gradle's code does not have a timeout on starting the
> process. But a successfully started process immediately connects to Gradle,
> and Gradle throws an exception if the connection doesn't happen within 2
> minutes.
> The {{DockerizedExecHandle}} timeout hides the real problem, which is that
> the process takes too long to start, or too long to report that it has
> started. Removing that timeout will allow Gradle to give better diagnostic
> information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9048) Remove the timeout on DockerizedExecHandle startup
Dale Emery created GEODE-9048:
-
Summary: Remove the timeout on DockerizedExecHandle startup
Key: GEODE-9048
URL: https://issues.apache.org/jira/browse/GEODE-9048
Project: Geode
Issue Type: Test
Components: tests
Affects Versions: 1.15.0
Reporter: Dale Emery
In the Dockerized test plugin, {{DockerizedExecHandle.start()}} throws a
timeout exception if the process does not start within 30 seconds. The error
handling code tries to abort the process, gets confused because the process has
not started, and throws an {{IllegalStateException}}, preventing Gradle from
reporting the original timeout exception.
{{DockerizedExecHandle.start()}} is a modified copy of the code from Gradle's
{{DefaultExecHandle}}. Gradle's code does not have a timeout on starting the
process. But a successfully started process immediately connects to Gradle, and
Gradle throws an exception if the connection doesn't happen within 2 minutes.
The {{DockerizedExecHandle}} timeout hides the real problem, which is that the
process takes too long to start, or too long to report that it has started.
Removing that timeout will allow Gradle to give better diagnostic information.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9049) ClientCache.close() functionality doesn't seem to match the Javadoc
John Martin created GEODE-9049:
--
Summary: ClientCache.close() functionality doesn't seem to match
the Javadoc
Key: GEODE-9049
URL: https://issues.apache.org/jira/browse/GEODE-9049
Project: Geode
Issue Type: Bug
Components: client/server
Affects Versions: 1.15.0
Reporter: John Martin
While writing a simple application, I found that the ClientCache.close() method
did not respond the way that was expected according to the Javadocs.
The application code was:
{code:java}
public static void main(String[] args) {
ClientCache cache = new ClientCacheFactory().addPoolLocator("127.0.0.1",
10334).create();
System.out.println(cache.getDefaultPool().getLocators());
cache.close();
System.out.println("Cache.close() called.");
System.out.println(cache.getDefaultPool().getLocators());
}
{code}
The output was:
{code:java}
[/127.0.0.1:10334]
Cache.close() called.
[/127.0.0.1:10334]
{code}
According to the Javadocs for the cache.close() method, it seems that after
calling cache.close() when a user calls cache.getDefaultPool().getLocators()
the user should receive a *CacheClosedException,* instead of the locator
address.
This can be found in the Javadocs under *Interface ClientCache* -> *close*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9049) ClientCache.close() functionality doesn't seem to match the Javadoc
[
https://issues.apache.org/jira/browse/GEODE-9049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Martin updated GEODE-9049:
---
Description:
While writing a simple application, I found that the ClientCache.close() method
did not respond the way that was expected according to the Javadocs.
The application code was:
{code:java}
public static void main(String[] args) {
ClientCache cache = new ClientCacheFactory().addPoolLocator("127.0.0.1",
10334).create();
System.out.println(cache.getDefaultPool().getLocators());
cache.close();
System.out.println("Cache.close() called.");
System.out.println(cache.getDefaultPool().getLocators());
}
{code}
The output was:
{code:java}
[/127.0.0.1:10334]
Cache.close() called.
[/127.0.0.1:10334]
{code}
According to the Javadocs for the [cache.close()
|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCache.html#close-boolean-]method,
it seems that after calling cache.close() when a user calls
cache.getDefaultPool().getLocators() the user should receive a
*CacheClosedException,* instead of the locator address.
This can be found in the Javadocs under *Interface ClientCache* -> *close*
was:
While writing a simple application, I found that the ClientCache.close() method
did not respond the way that was expected according to the Javadocs.
The application code was:
{code:java}
public static void main(String[] args) {
ClientCache cache = new ClientCacheFactory().addPoolLocator("127.0.0.1",
10334).create();
System.out.println(cache.getDefaultPool().getLocators());
cache.close();
System.out.println("Cache.close() called.");
System.out.println(cache.getDefaultPool().getLocators());
}
{code}
The output was:
{code:java}
[/127.0.0.1:10334]
Cache.close() called.
[/127.0.0.1:10334]
{code}
According to the Javadocs for the cache.close() method, it seems that after
calling cache.close() when a user calls cache.getDefaultPool().getLocators()
the user should receive a *CacheClosedException,* instead of the locator
address.
This can be found in the Javadocs under *Interface ClientCache* -> *close*
> ClientCache.close() functionality doesn't seem to match the Javadoc
> ---
>
> Key: GEODE-9049
> URL: https://issues.apache.org/jira/browse/GEODE-9049
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: John Martin
>Priority: Major
>
> While writing a simple application, I found that the ClientCache.close()
> method did not respond the way that was expected according to the Javadocs.
>
> The application code was:
>
> {code:java}
> public static void main(String[] args) {
> ClientCache cache = new ClientCacheFactory().addPoolLocator("127.0.0.1",
> 10334).create();
> System.out.println(cache.getDefaultPool().getLocators());
> cache.close();
>
> System.out.println("Cache.close() called.");
>
> System.out.println(cache.getDefaultPool().getLocators());
> }
> {code}
> The output was:
> {code:java}
> [/127.0.0.1:10334]
> Cache.close() called.
> [/127.0.0.1:10334]
> {code}
> According to the Javadocs for the [cache.close()
> |https://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientCache.html#close-boolean-]method,
> it seems that after calling cache.close() when a user calls
> cache.getDefaultPool().getLocators() the user should receive a
> *CacheClosedException,* instead of the locator address.
> This can be found in the Javadocs under *Interface ClientCache* -> *close*
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9037) Do not expose unsupported commands in Geode compatibility with Redis
[ https://issues.apache.org/jira/browse/GEODE-9037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9037: -- Labels: blocks-1.14.0 pull-request-available (was: blocks-1.14.0) > Do not expose unsupported commands in Geode compatibility with Redis > > > Key: GEODE-9037 > URL: https://issues.apache.org/jira/browse/GEODE-9037 > Project: Geode > Issue Type: New Feature > Components: redis >Reporter: Raymond Ingles >Assignee: Raymond Ingles >Priority: Major > Labels: blocks-1.14.0, pull-request-available > > The distinction between 'supported' and 'unsupported' commands is no longer > useful and will be removed. Any commands still listed as unsupported will now > respond if they were unimplemented/unknown. > A system property will allow them to be enabled solely for tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-6413) CI Failure: Bind Exception during ClusterCommunicationsDUnitTest.performARollingUpgrade
[
https://issues.apache.org/jira/browse/GEODE-6413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304496#comment-17304496
]
Geode Integration commented on GEODE-6413:
--
Seen in [DistributedTestOpenJDK8
#85|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/85]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0066/test-results/distributedTest/1616104235/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0066/test-artifacts/1616104235/distributedtestfiles-OpenJDK8-1.15.0-build.0066.tgz].
> CI Failure: Bind Exception during
> ClusterCommunicationsDUnitTest.performARollingUpgrade
> ---
>
> Key: GEODE-6413
> URL: https://issues.apache.org/jira/browse/GEODE-6413
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Benjamin P Ross
>Priority: Major
> Fix For: 1.9.0
>
>
> Stack Trace:
> {noformat}
> org.apache.geode.ClusterCommunicationsDUnitTest >
> performARollingUpgrade[SHARED_CONNECTIONS] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> c4dd6cb2c206 with 3 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.performARollingUpgrade(ClusterCommunicationsDUnitTest.java:214)
> Caused by:
> java.net.BindException: Failed to create server socket on
> c4dd6cb2c206/172.17.0.16[43969]
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:756)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:714)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:680)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:225)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:215)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:210)
> at
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:501)
> at
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:557)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:340)
> at
> org.apache.geode.distributed.Locator.startLocator(Locator.java:252)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:139)
> at
> org.apache.geode.ClusterCommunicationsDUnitTest.lambda$null$1(ClusterCommunicationsDUnitTest.java:220)
> Caused by:
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:753)
> ... 11 more
> {noformat}
> This test may be fixed with a longer await() timeout.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9050) redis test fails with Jetty 4.1.60
[
https://issues.apache.org/jira/browse/GEODE-9050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols reassigned GEODE-9050:
---
Assignee: Jens Deppe
> redis test fails with Jetty 4.1.60
> --
>
> Key: GEODE-9050
> URL: https://issues.apache.org/jira/browse/GEODE-9050
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Assignee: Jens Deppe
>Priority: Major
>
> {{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
> [fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
> reliably, on both Linux and Windows, if I [bump
> Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
> from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
> latest versions of our 3rd-party dependencies but breaking this out
> separately so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9050) redis test fails with Jetty 4.1.60
Owen Nichols created GEODE-9050:
---
Summary: redis test fails with Jetty 4.1.60
Key: GEODE-9050
URL: https://issues.apache.org/jira/browse/GEODE-9050
Project: Geode
Issue Type: Bug
Components: redis
Affects Versions: 1.15.0
Reporter: Owen Nichols
{{PubSubIntegrationTest > ensureOrderingOfPublishedMessages}}
[fails|http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-6153/test-results/integrationTest/1616031328/index.html]
reliably, on both Linux and Windows, if I [bump
Netty|https://github.com/apache/geode/pull/6153/commits/03b81f93b011377a5021a4b87acecacfa02b93a4]
from 4.1.59.Final to 4.1.60.Final. It's important to keep up to date with
latest versions of our 3rd-party dependencies but breaking this out separately
so someone with redis knowledge can tackle it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8950) Benchmark failure - P2pPartitionedPutLongBenchmark
[ https://issues.apache.org/jira/browse/GEODE-8950?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304575#comment-17304575 ] Donal Evans commented on GEODE-8950: Evidence from bisecting with repeat benchmark runs suggests that the performance degradation seen here was introduced by GEODE-8496: top up dependency updates (#5772), SHA 217be41f. This commit included 20 dependency updates, so further bisection is needed to identify which of the dependency updates caused the performance degradation. > Benchmark failure - P2pPartitionedPutLongBenchmark > -- > > Key: GEODE-8950 > URL: https://issues.apache.org/jira/browse/GEODE-8950 > Project: Geode > Issue Type: Bug > Components: benchmarks >Affects Versions: 1.15.0 >Reporter: Donal Evans >Assignee: Donal Evans >Priority: Major > Labels: blocks-1.14.0, blocks-1.15.0 > > Multiple benchmark failures due to P2pPartitionedPutLongBenchmark have been > seen recently. > This run saw 3 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/16#L601ed52d:5552] > This run saw 1 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/20] > This run saw 4 out of the 5 repeats fail due to flagged degradations in > P2pPartitionedPutLongBenchmark: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/27] > In all the above benchmarks, the other failed runs were due to EOFExceptions > rather than flagged degradations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304599#comment-17304599 ] ASF subversion and git services commented on GEODE-9019: Commit b0c7ddef3ac06699feec143f5527b9a9af38eb01 in geode's branch refs/heads/feature/redis-performance-testing from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b0c7dde ] GEODE-9019: Serialization improvements in geode-redis (#6115) GEODE-9019: Serialization improvements in geode-redis (#6115) * DataSerializable classes were converted in DataSerializableFixedID * serialVersionID were added to the unavoidable Serializable classes GEODE-9019: Fixed synchronization blocks missed in previous commit (#6123) * Added tests to validate synchronized modifiers. * Enum serialization fixed, comments updated * Fixed the pom error - geode-membership in geode-redis (cherry picked from commit 7aae7b8158a0c8aecc15468a81a421bd6ffdc05e) (cherry picked from commit 0b9c6b125d093d1e007527cf0e4d6ac2e419f6d1) > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304597#comment-17304597 ] ASF subversion and git services commented on GEODE-9019: Commit b0c7ddef3ac06699feec143f5527b9a9af38eb01 in geode's branch refs/heads/feature/redis-performance-testing from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b0c7dde ] GEODE-9019: Serialization improvements in geode-redis (#6115) GEODE-9019: Serialization improvements in geode-redis (#6115) * DataSerializable classes were converted in DataSerializableFixedID * serialVersionID were added to the unavoidable Serializable classes GEODE-9019: Fixed synchronization blocks missed in previous commit (#6123) * Added tests to validate synchronized modifiers. * Enum serialization fixed, comments updated * Fixed the pom error - geode-membership in geode-redis (cherry picked from commit 7aae7b8158a0c8aecc15468a81a421bd6ffdc05e) (cherry picked from commit 0b9c6b125d093d1e007527cf0e4d6ac2e419f6d1) > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9019) Convert all redis data structures to DataSerializableFixedID
[ https://issues.apache.org/jira/browse/GEODE-9019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304598#comment-17304598 ] ASF subversion and git services commented on GEODE-9019: Commit b0c7ddef3ac06699feec143f5527b9a9af38eb01 in geode's branch refs/heads/feature/redis-performance-testing from Nabarun Nag [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b0c7dde ] GEODE-9019: Serialization improvements in geode-redis (#6115) GEODE-9019: Serialization improvements in geode-redis (#6115) * DataSerializable classes were converted in DataSerializableFixedID * serialVersionID were added to the unavoidable Serializable classes GEODE-9019: Fixed synchronization blocks missed in previous commit (#6123) * Added tests to validate synchronized modifiers. * Enum serialization fixed, comments updated * Fixed the pom error - geode-membership in geode-redis (cherry picked from commit 7aae7b8158a0c8aecc15468a81a421bd6ffdc05e) (cherry picked from commit 0b9c6b125d093d1e007527cf0e4d6ac2e419f6d1) > Convert all redis data structures to DataSerializableFixedID > > > Key: GEODE-9019 > URL: https://issues.apache.org/jira/browse/GEODE-9019 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Nabarun Nag >Assignee: Nabarun Nag >Priority: Major > Labels: blocks-1.14.0, pull-request-available > Fix For: 1.14.0 > > > Issue: > * Currently, a couple of redis data structures are using DataSerializable > * This will cause issues during rolling upgrade > Solution: > * Convert these data structures to DataSerializableFixedIDs. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
