[jira] [Commented] (GEODE-6296) CI failure: CqResultSetUsingPoolOptimizedExecuteDUnitTest.testCqResultsCachingForMultipleCQs
[
https://issues.apache.org/jira/browse/GEODE-6296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17058317#comment-17058317
]
Mark Hanson commented on GEODE-6296:
CI failure of CqResultSetUsingPoolDUnitTest > testCqResultsCachingWithFailOver
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1644
{noformat}
org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolDUnitTest >
testCqResultsCachingWithFailOver FAILED
15:53:42org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolDUnitTest$24.run in
VM 0 running on Host 470f1e2e2bf5 with 4 VMs
15:53:42at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
15:53:42at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
15:53:42at
org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolDUnitTest.testCqResultsCachingWithFailOver(CqResultSetUsingPoolDUnitTest.java:1009)
15:53:42
15:53:42Caused by:
15:53:42java.lang.AssertionError: The number of keys cached for cq
testCQFailOver_0 is wrong. expected:<500> but was:<499>
15:53:42at org.junit.Assert.fail(Assert.java:88)
15:53:42at org.junit.Assert.failNotEquals(Assert.java:834)
15:53:42at org.junit.Assert.assertEquals(Assert.java:645)
15:53:42at
org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolDUnitTest$24.run2(CqResultSetUsingPoolDUnitTest.java:1049)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
17:26:18http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0087/test-results/distributedTest/1584058743/
17:26:18=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
17:26:18
17:26:18Test report artifacts from this job are available at:
17:26:18
17:26:18http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0087/test-artifacts/1584058743/distributedtestfiles-OpenJDK8-1.13.0-SNAPSHOT.0087.tgz
{noformat}
> CI failure:
> CqResultSetUsingPoolOptimizedExecuteDUnitTest.testCqResultsCachingForMultipleCQs
>
>
> Key: GEODE-6296
> URL: https://issues.apache.org/jira/browse/GEODE-6296
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Bruce J Schuchardt
>Assignee: Dan Smith
>Priority: Major
> Labels: CI
>
> Test failed in CI run
> [308|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/308]
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolOptimizedExecuteDUnitTest
> > testCqResultsCachingForMultipleCQs FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.cq.dunit.CqResultSetUsingPoolDUnitTest$13.run in
> VM 0 running on Host 1d74fe6e98cf with 4 VMs
> Caused by:
> java.lang.AssertionError: The number of keys cached for cq
> testCqResultsP_1 is wrong. expected:<500> but was:<499>
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7876) OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap
[ https://issues.apache.org/jira/browse/GEODE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7876: --- Labels: flaky (was: ) > OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap > --- > > Key: GEODE-7876 > URL: https://issues.apache.org/jira/browse/GEODE-7876 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.12.0 >Reporter: Mark Hanson >Priority: Major > Labels: flaky > > CI Failure > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1587 > > Test worker" #27 prio=5 os_prio=0 cpu=7943.09ms elapsed=1126.77s > tid=0x7f60e0b7e000 nid=0x19 in Object.wait() [0x7f60a2a4b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base@11.0.6/Native Method) > - waiting on > at > org.apache.geode.internal.cache.DiskStoreImpl.waitForBackgroundTasks(DiskStoreImpl.java:2630) > - waiting to re-lock in wait() <0xffbb6438> (a > java.util.concurrent.atomic.AtomicInteger) > at > org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2386) > at > org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2296) > at > org.apache.geode.internal.cache.GemFireCacheImpl.closeDiskStores(GemFireCacheImpl.java:2476) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2234) > - locked <0xd0a42a00> (a java.lang.Class for > org.apache.geode.internal.cache.GemFireCacheImpl) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1931) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1921) > at > org.apache.geode.internal.offheap.OffHeapRegionBase.closeCache(OffHeapRegionBase.java:106) > at > org.apache.geode.internal.offheap.OffHeapRegionBase.testPersistentChangeFromHeapToOffHeap(OffHeapRegionBase.java:675) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) > at >
[jira] [Updated] (GEODE-7876) OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap
[ https://issues.apache.org/jira/browse/GEODE-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7876: --- Affects Version/s: 1.12.0 > OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap > --- > > Key: GEODE-7876 > URL: https://issues.apache.org/jira/browse/GEODE-7876 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.12.0 >Reporter: Mark Hanson >Priority: Major > > CI Failure > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1587 > > Test worker" #27 prio=5 os_prio=0 cpu=7943.09ms elapsed=1126.77s > tid=0x7f60e0b7e000 nid=0x19 in Object.wait() [0x7f60a2a4b000] >java.lang.Thread.State: TIMED_WAITING (on object monitor) > at java.lang.Object.wait(java.base@11.0.6/Native Method) > - waiting on > at > org.apache.geode.internal.cache.DiskStoreImpl.waitForBackgroundTasks(DiskStoreImpl.java:2630) > - waiting to re-lock in wait() <0xffbb6438> (a > java.util.concurrent.atomic.AtomicInteger) > at > org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2386) > at > org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2296) > at > org.apache.geode.internal.cache.GemFireCacheImpl.closeDiskStores(GemFireCacheImpl.java:2476) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2234) > - locked <0xd0a42a00> (a java.lang.Class for > org.apache.geode.internal.cache.GemFireCacheImpl) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1931) > at > org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1921) > at > org.apache.geode.internal.offheap.OffHeapRegionBase.closeCache(OffHeapRegionBase.java:106) > at > org.apache.geode.internal.offheap.OffHeapRegionBase.testPersistentChangeFromHeapToOffHeap(OffHeapRegionBase.java:675) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native > Method) > at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) > at >
[jira] [Created] (GEODE-7876) OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap
Mark Hanson created GEODE-7876: -- Summary: OldFreeListOffHeapRegionJUnitTest testPersistentChangeFromHeapToOffHeap Key: GEODE-7876 URL: https://issues.apache.org/jira/browse/GEODE-7876 Project: Geode Issue Type: Bug Components: tests Reporter: Mark Hanson CI Failure https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1587 Test worker" #27 prio=5 os_prio=0 cpu=7943.09ms elapsed=1126.77s tid=0x7f60e0b7e000 nid=0x19 in Object.wait() [0x7f60a2a4b000] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(java.base@11.0.6/Native Method) - waiting on at org.apache.geode.internal.cache.DiskStoreImpl.waitForBackgroundTasks(DiskStoreImpl.java:2630) - waiting to re-lock in wait() <0xffbb6438> (a java.util.concurrent.atomic.AtomicInteger) at org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2386) at org.apache.geode.internal.cache.DiskStoreImpl.close(DiskStoreImpl.java:2296) at org.apache.geode.internal.cache.GemFireCacheImpl.closeDiskStores(GemFireCacheImpl.java:2476) at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2234) - locked <0xd0a42a00> (a java.lang.Class for org.apache.geode.internal.cache.GemFireCacheImpl) at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1931) at org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1921) at org.apache.geode.internal.offheap.OffHeapRegionBase.closeCache(OffHeapRegionBase.java:106) at org.apache.geode.internal.offheap.OffHeapRegionBase.testPersistentChangeFromHeapToOffHeap(OffHeapRegionBase.java:675) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at org.junit.runners.ParentRunner.run(ParentRunner.java:363) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62) at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.6/Native Method) at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.6/NativeMethodAccessorImpl.java:62) at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.6/DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(java.base@11.0.6/Method.java:566) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) at
[jira] [Updated] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson updated GEODE-6222:
---
Labels: flaky (was: )
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0
>Reporter: Ken Howe
>Priority: Major
> Labels: flaky
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7804) OperationResult should have some methods on it
[ https://issues.apache.org/jira/browse/GEODE-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-7804. - Fix Version/s: 1.13.0 Resolution: Fixed > OperationResult should have some methods on it > -- > > Key: GEODE-7804 > URL: https://issues.apache.org/jira/browse/GEODE-7804 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.13.0 > > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.geode.management.runtime.OperationResult currently is just a > marker interface (has no methods). But it should have some. > At the very least it should have the following: > String getStatusMessage(); > boolean getSuccess(); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols resolved GEODE-7829. - Resolution: Fixed > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7875) The gfsh create index command sometimes fails with 'Index already exists. Create failed due to duplicate name.' message
Barrett Oglesby created GEODE-7875:
--
Summary: The gfsh create index command sometimes fails with 'Index
already exists. Create failed due to duplicate name.' message
Key: GEODE-7875
URL: https://issues.apache.org/jira/browse/GEODE-7875
Project: Geode
Issue Type: Bug
Components: gfsh, querying
Reporter: Barrett Oglesby
Here is output from the connect, list indexes, create index commands:
{noformat}
(1) Executing - connect --locator=localhost[23456]
Connecting to Locator at [host=localhost, port=23456] ..
Connecting to Manager at [host=boglesbymac.local, port=1099] ..
Successfully connected to: [host=boglesbymac.local, port=1099]
(2) Executing - list indexes
No Indexes Found
(3) Executing - create index --name=cusip_index_1 --expression=cusip
--region=/Trades
Member| Status | Message
| -- |
---
192.168.1.4(server1:88452):41001 | ERROR | Index "cusip_index_1" already
exists. Create failed due to duplicate name.
192.168.1.4(server2:88465):41002 | OK | Index successfully created
192.168.1.4(server3:88473):41003 | ERROR | Index "cusip_index_1" already
exists. Create failed due to duplicate name.
192.168.1.4(server4:88480):41004 | ERROR | Index "cusip_index_1" already
exists. Create failed due to duplicate name.
{noformat}
Here is some logging that shows the behavior:
server2 executes the CreateIndexFunction and creates the index locally:
{noformat}
[warn 2020/03/12 16:18:11.273 PDT tid=0x54] XXX
CreateIndexFunction.execute indexName=cusip_index_1
[info 2020/03/12 16:18:11.297 PDT tid=0x54]
Created index locally, sending index creation message to all members, and will
be waiting for response Index [ Name=cusip_index_1 Type =FUNCTIONAL
IdxExp=cusip From=/Trades Proj=*]imports : null.
{noformat}
It sends the IndexCreationMsg to servers 1, 3 and 4 and processes the response:
{noformat}
[warn 2020/03/12 16:18:11.297 PDT tid=0x54] XXX
IndexCreationMsg.send indMsg=cusip_index_1
[warn 2020/03/12 16:18:11.298 PDT tid=0x54] XXX
PartitionedRegion.createIndex response=:41001,
192.168.1.4(server3:88473):41003, 192.168.1.4(server4:88480):41004]>
{noformat}
servers 1, 3 and 4 receive the IndexCreationMsg, creates the index and respond:
{noformat}
[warn 2020/03/12 16:18:11.298 PDT
tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion about to createIndexes
[warn 2020/03/12 16:18:11.304 PDT
tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion done createIndexes
{noformat}
Then they execute the CreateIndexFunction to create the index locally which
fails:
{noformat}
[warn 2020/03/12 16:18:11.501 PDT tid=0x4e] XXX
CreateIndexFunction.execute indexName=cusip_index_1
[warn 2020/03/12 16:18:11.521 PDT tid=0x4e] XXX
CreateIndexFunction.execute failed due to IndexNameConflictException:
org.apache.geode.cache.query.IndexNameConflictException: Index named '
cusip_index_1 ' already exists.
at
org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453)
at
org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8403)
at
org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245)
at
org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203)
at
org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274)
at
org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:177)
at
org.apache.geode.management.internal.cli.functions.CreateIndexFunction.execute(CreateIndexFunction.java:62)
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-7874) write a serialization backward-compatibility test for geode-membership
[ https://issues.apache.org/jira/browse/GEODE-7874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-7874: - Assignee: Bruce J Schuchardt > write a serialization backward-compatibility test for geode-membership > -- > > Key: GEODE-7874 > URL: https://issues.apache.org/jira/browse/GEODE-7874 > Project: Geode > Issue Type: Improvement > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > > We moved membership classes into geode-membership but have yet to implement a > variant of AnalyzeSerializablesJUnitTest for this module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7874) write a serialization backward-compatibility test for geode-membership
Bruce J Schuchardt created GEODE-7874: - Summary: write a serialization backward-compatibility test for geode-membership Key: GEODE-7874 URL: https://issues.apache.org/jira/browse/GEODE-7874 Project: Geode Issue Type: Improvement Components: membership Reporter: Bruce J Schuchardt We moved membership classes into geode-membership but have yet to implement a variant of AnalyzeSerializablesJUnitTest for this module. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7804) OperationResult should have some methods on it
[ https://issues.apache.org/jira/browse/GEODE-7804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-7804: --- Assignee: Darrel Schneider > OperationResult should have some methods on it > -- > > Key: GEODE-7804 > URL: https://issues.apache.org/jira/browse/GEODE-7804 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > org.apache.geode.management.runtime.OperationResult currently is just a > marker interface (has no methods). But it should have some. > At the very least it should have the following: > String getStatusMessage(); > boolean getSuccess(); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7825) can see exception info when I try to run rebalance by REST API
[
https://issues.apache.org/jira/browse/GEODE-7825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-7825:
---
Assignee: Darrel Schneider
> can see exception info when I try to run rebalance by REST API
> --
>
> Key: GEODE-7825
> URL: https://issues.apache.org/jira/browse/GEODE-7825
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Darrel Schneider
>Priority: Major
>
> as a user, when I try to run rebalance by [POST]
> "http://127.0.0.1:7070/management/v1/operations/rebalances;
> , sometimes can get the following response:
> {code:java}
> {
> "statusCode": "ACCEPTED",
> "statusMessage": "Operation started. Use the URI to check its status.",
> "links": {
> "self":
> "http://127.0.0.1:7070/management/v1/operations/rebalances/7c39a7f0-6b7e-4177-9269-bfa7ce42808d;,
> "list": "http://127.0.0.1:7070/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-27T22:48:49.716Z",
> "operationEnd": "2020-02-27T22:48:49.729Z",
> "operationId": "7c39a7f0-6b7e-4177-9269-bfa7ce42808d",
> "operation": {
> "simulate": false
> },
> "throwable": {
> "stackTrace": [
> {
> "methodName": "getMemberRegionList",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 208,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "executeRebalanceOnDS",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 326,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "perform",
> "fileName": "RebalanceOperationPerformer.java",
> "lineNumber": 91,
> "className":
> "org.apache.geode.management.internal.operation.RebalanceOperationPerformer",
> "nativeMethod": false
> },
> {
> "methodName": "lambda$submit$0",
> "fileName": "OperationManager.java",
> "lineNumber": 67,
> "className":
> "org.apache.geode.management.internal.operation.OperationManager",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "CompletableFuture.java",
> "lineNumber": 1590,
> "className":
> "java.util.concurrent.CompletableFuture$AsyncSupply",
> "nativeMethod": false
> },
> {
> "methodName": "run",
> "fileName": "Thread.java",
> "lineNumber": 748,
> "className": "java.lang.Thread",
> "nativeMethod": false
> }
> ]
> }
> }
> {code}
> if a post request of a-sync operation , as rebalance , is posted, the user
> wants to see whether it is accepted or not. When the user want to know
> detail info, he just needs to run
> [GET]
> http://127.0.0.1:7070/management/experimental/operations/rebalances/[operationID]
> to get more information.
> expected result: just show accepted or not, without throwable info
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7873) CI Failure: DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
Ivan Godwin created GEODE-7873:
--
Summary: CI Failure:
DeployJarWithSSLDUnitTest.deployJarWithMultipleLocators
Key: GEODE-7873
URL: https://issues.apache.org/jira/browse/GEODE-7873
Project: Geode
Issue Type: Bug
Reporter: Ivan Godwin
DeployJarWithSSLDUnitTest > deployJarWithMultipleLocators failed with the
following output:
{code:java}
org.apache.geode.management.internal.configuration.DeployJarWithSSLDUnitTest >
deployJarWithMultipleLocators FAILEDjava.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 1966
[fatal 2020/03/11 17:43:42.352 GMT tid=82] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.9(server-2:123):41002 started at Wed Mar
11 17:43:37 GMT 2020: Message distribution has terminated at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
at java.lang.Thread.run(Thread.java:748)
---
Found suspect string in log4j at line 1975
[fatal 2020/03/11 17:43:42.362 GMT tid=65] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.9(server-2:123):41002 started at Wed Mar
11 17:43:37 GMT 2020: Message distribution has terminated at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
at java.lang.Thread.run(Thread.java:748)
{code}
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1637
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-6499) PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 60000 milliseconds for AsyncInvocation to complete.
[
https://issues.apache.org/jira/browse/GEODE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Godwin reopened GEODE-6499:
> PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
>
>
> Key: GEODE-6499
> URL: https://issues.apache.org/jira/browse/GEODE-6499
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Attachments: PersistentColocatedPartitionedRegionDUnitTest.tgz
>
>
> {noformat}
>
> Task :geode-core:distributedTest
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:979)
>
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testMultipleColocatedChildPRsMissingWithSequencedStart FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:865)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-6499) PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 60000 milliseconds for AsyncInvocation to complete.
[
https://issues.apache.org/jira/browse/GEODE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17058137#comment-17058137
]
Ivan Godwin commented on GEODE-6499:
Failed in CI
([https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1638)
with following
output:|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1638):]
{code:java}
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest
> testMissingColocatedChildPRDueToDelayedStart FAILED
java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed out
waiting 30 milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:180)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.testMissingColocatedChildPRDueToDelayedStart(PersistentColocatedPartitionedRegionDistributedTest.java:419)
Caused by:
java.util.concurrent.TimeoutException: Timed out waiting 30
milliseconds for AsyncInvocation to complete.
at
org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:509)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:447)
at
org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:178)
... 1 more
Caused by:
org.apache.geode.test.dunit.internal.StackTrace: Stack trace for
vm-0 thread-32
at java.lang.Object.wait(Native Method)
at
org.apache.geode.internal.cache.persistence.MembershipChangeListener.waitForChange(MembershipChangeListener.java:68)
at
org.apache.geode.internal.cache.BucketPersistenceAdvisor.initializeMembershipView(BucketPersistenceAdvisor.java:254)
at
org.apache.geode.internal.cache.ProxyBucketRegion.recoverFromDisk(ProxyBucketRegion.java:491)
at
org.apache.geode.internal.cache.ProxyBucketRegion.recoverFromDiskRecursively(ProxyBucketRegion.java:406)
at
org.apache.geode.internal.cache.PRHARedundancyProvider.recoverPersistentBuckets(PRHARedundancyProvider.java:1661)
at
org.apache.geode.internal.cache.PartitionedRegion.initPRInternals(PartitionedRegion.java:1083)
at
org.apache.geode.internal.cache.PartitionedRegion.initialize(PartitionedRegion.java:1193)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:2971)
at
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2869)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2853)
at
org.apache.geode.cache.RegionFactory.create(RegionFactory.java:773)
at
org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:75)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.createChildPR_withPersistence(PersistentColocatedPartitionedRegionDistributedTest.java:1746)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.validateColocationLogger_withChildRegion(PersistentColocatedPartitionedRegionDistributedTest.java:1922)
at
org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDistributedTest.lambda$testMissingColocatedChildPRDueToDelayedStart$7be3218f$1(PersistentColocatedPartitionedRegionDistributedTest.java:415)
{code}
> PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
>
>
> Key: GEODE-6499
> URL: https://issues.apache.org/jira/browse/GEODE-6499
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Labels: flaky
> Fix For: 1.12.0
>
> Attachments: PersistentColocatedPartitionedRegionDUnitTest.tgz
>
>
> {noformat}
>
> Task :geode-core:distributedTest
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at
[jira] [Created] (GEODE-7872) Stop globbing sources in unit tests (cppcache/test/CMakeLists.txt)
Blake Bender created GEODE-7872: --- Summary: Stop globbing sources in unit tests (cppcache/test/CMakeLists.txt) Key: GEODE-7872 URL: https://issues.apache.org/jira/browse/GEODE-7872 Project: Geode Issue Type: Task Components: native client Reporter: Blake Bender Fix For: 1.12.0 This messes up automatic reconfiguration via CMake build command, and is discouraged as bad practice. Replace with explicit list of source files. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7871) CI Failure: ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey Failed
Ivan Godwin created GEODE-7871:
--
Summary: CI Failure:
ClientServerHostNameVerificationDistributedTest.expectConnectionFailureWhenNoHostNameInLocatorKey
Failed
Key: GEODE-7871
URL: https://issues.apache.org/jira/browse/GEODE-7871
Project: Geode
Issue Type: Bug
Reporter: Ivan Godwin
ClientServerHostNameVerificationDistributedTest >
expectConnectionFailureWhenNoHostNameInLocatorKey failed with the following
output:
{code:java}
org.apache.geode.cache.client.internal.ClientServerHostNameVerificationDistributedTest
> expectConnectionFailureWhenNoHostNameInLocatorKey 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 3602
[fatal 2020/03/12 02:42:26.780 GMT tid=94] Uncaught
exception in thread Thread[unused p2p reader,5,RMI Runtime]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on 172.17.0.14(server-2:95):41002 started at Thu Mar
12 02:42:11 GMT 2020: Message distribution has terminated
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2872)
at
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1666)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1446)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1621
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-5543) LuceneQueryFactory API for Geode Native (C++ & C#)
[
https://issues.apache.org/jira/browse/GEODE-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-5543.
-
Resolution: Won't Fix
This support isn't going to rise to the level of a fix or enhancement for a
very long time, if ever. Resolving/closing for now to keep the bug database
tidy. If Lucene ever becomes important enough for us to need this, it'll come
up again in planning and we'll create a new issue.
> LuceneQueryFactory API for Geode Native (C++ & C#)
> --
>
> Key: GEODE-5543
> URL: https://issues.apache.org/jira/browse/GEODE-5543
> Project: Geode
> Issue Type: New Feature
> Components: native client
>Reporter: Addison
>Priority: Major
>
> Currently, Geode Native does not have the ability to call Lucene indexes
> directly. The aim of this story is to provide an API similar to the remote
> query service that allows users to make queries against Lucene indices.
> The Java client exposes a Lucene query service and factory method.
> {code:java}
> LuceneService lucene = LuceneServiceProvider.get(cache);
> LuceneQuery query =
> lucene.createLuceneQueryFactory().create(SIMPLE_INDEX, EXAMPLE_REGION,
> "firstName:Chris~2", "firstname");
> result = query.findValues());{code}
> Geode Native should do something similar to the remote query service. For
> example:
> C++
> {code:java}
> std::shared_ptr luceneService = nullptr;
> luceneService = pool->getLuceneService();
> LuceneFactory lf = luceneService::createLuceneQueryFactory();
> auto query = lf.create(SIMPLE_INDEX, EXAMPLE_REGION, "firstName:Chris~2",
> "firstname");
> auto results = query->findValues(); {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (GEODE-5543) LuceneQueryFactory API for Geode Native (C++ & C#)
[
https://issues.apache.org/jira/browse/GEODE-5543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-5543.
---
> LuceneQueryFactory API for Geode Native (C++ & C#)
> --
>
> Key: GEODE-5543
> URL: https://issues.apache.org/jira/browse/GEODE-5543
> Project: Geode
> Issue Type: New Feature
> Components: native client
>Reporter: Addison
>Priority: Major
>
> Currently, Geode Native does not have the ability to call Lucene indexes
> directly. The aim of this story is to provide an API similar to the remote
> query service that allows users to make queries against Lucene indices.
> The Java client exposes a Lucene query service and factory method.
> {code:java}
> LuceneService lucene = LuceneServiceProvider.get(cache);
> LuceneQuery query =
> lucene.createLuceneQueryFactory().create(SIMPLE_INDEX, EXAMPLE_REGION,
> "firstName:Chris~2", "firstname");
> result = query.findValues());{code}
> Geode Native should do something similar to the remote query service. For
> example:
> C++
> {code:java}
> std::shared_ptr luceneService = nullptr;
> luceneService = pool->getLuceneService();
> LuceneFactory lf = luceneService::createLuceneQueryFactory();
> auto query = lf.create(SIMPLE_INDEX, EXAMPLE_REGION, "firstName:Chris~2",
> "firstname");
> auto results = query->findValues(); {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7830) Management REST API rebalance endpoints return confusing operationResults
[
https://issues.apache.org/jira/browse/GEODE-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-7830.
-
Fix Version/s: 1.13.0
Resolution: Fixed
> Management REST API rebalance endpoints return confusing operationResults
> -
>
> Key: GEODE-7830
> URL: https://issues.apache.org/jira/browse/GEODE-7830
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Aaron Lindsey
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.13.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> We observed odd behavior regarding the operationResult object returned in the
> rebalance API:
> # It contains success=false if the cluster has no regions or has no servers.
> This is confusing because the rebalance didn't fail — it just didn't have
> anything to rebalance so it was basically a no-op. As a consumer of this API,
> I need to be able to distinguish between "real" failures and this "no-op"
> failure, and I should not have to write code to parse the "statusMessage" to
> do that.
> # Sometimes, success=true and other times success=false for the same
> statusMessage: "Distributed system has no regions that can be rebalanced."
> This is confusing because I don't know why it sometimes considers this a
> failure and other times considers it a success. If #1 above is fixed, then
> this would not be an issue because it would always return success=true for
> this particular statusMessage.
> Here is an example of two confusing operationResults we observed:
> {code:json}
> {
> "result": [
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/15dfe6ef-acaf-4a45-9b55-1d855a977ba8;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:34.058Z",
> "operationEnd": "2020-02-25T18:53:34.063Z",
> "operationId": "15dfe6ef-acaf-4a45-9b55-1d855a977ba8",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": true
> }
> },
> {
> "statusCode": "OK",
> "links": {
> "self":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances/8218ce0d-e3b8-4c49-b925-665a28e821c3;,
> "list":
> "http://geodecluster-sample-locator.default/management/v1/operations/rebalances;
> },
> "operationStart": "2020-02-25T18:53:45.650Z",
> "operationEnd": "2020-02-25T18:53:45.654Z",
> "operationId": "8218ce0d-e3b8-4c49-b925-665a28e821c3",
> "operation": {
> "simulate": false
> },
> "operationResult": {
> "statusMessage": "Distributed system has no regions that can be
> rebalanced.",
> "success": false
> }
> }
> ],
> "statusCode": "OK"
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-5259) DataSerializable objects should not have fixed ClassId properties
[ https://issues.apache.org/jira/browse/GEODE-5259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-5259. - Fix Version/s: 1.10.0 Resolution: Fixed Old crusty bug, linked PRs were merged ~18 months ago. Resolving fixed. > DataSerializable objects should not have fixed ClassId properties > - > > Key: GEODE-5259 > URL: https://issues.apache.org/jira/browse/GEODE-5259 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Like the Java version of these classes the ClassId should be registered with > the Class and on a per Cache/DS basis. > > Remove ClassId from DataSerializable and add it to the > TypeRegistry::RegisteryType call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-5259) DataSerializable objects should not have fixed ClassId properties
[ https://issues.apache.org/jira/browse/GEODE-5259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-5259. --- > DataSerializable objects should not have fixed ClassId properties > - > > Key: GEODE-5259 > URL: https://issues.apache.org/jira/browse/GEODE-5259 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Priority: Major > Labels: pull-request-available > Fix For: 1.10.0 > > Time Spent: 11h 20m > Remaining Estimate: 0h > > Like the Java version of these classes the ClassId should be registered with > the Class and on a per Cache/DS basis. > > Remove ClassId from DataSerializable and add it to the > TypeRegistry::RegisteryType call. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-3394) Failure to load authentication assembly should log exception
[ https://issues.apache.org/jira/browse/GEODE-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-3394. --- > Failure to load authentication assembly should log exception > > > Key: GEODE-3394 > URL: https://issues.apache.org/jira/browse/GEODE-3394 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Priority: Major > > Currently if the authentication module assembly fails to load the exception > is ignored and a generic message is logged. The original exception should > also be logged to help diagnose loading issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-3394) Failure to load authentication assembly should log exception
[ https://issues.apache.org/jira/browse/GEODE-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-3394. - Resolution: Won't Fix This is no longer applicable, since the native client has changed the authentication API so that clients pass an object reference to IAuthInitialize, rather than specifying an authentication assembly. > Failure to load authentication assembly should log exception > > > Key: GEODE-3394 > URL: https://issues.apache.org/jira/browse/GEODE-3394 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob Barrett >Priority: Major > > Currently if the authentication module assembly fails to load the exception > is ignored and a generic message is logged. The original exception should > also be logged to help diagnose loading issues. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5736) Native Client examples: Build fails outside installed product directory tree
[ https://issues.apache.org/jira/browse/GEODE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-5736. - Fix Version/s: 1.12.0 Resolution: Fixed Tried this on my Macbook this morning, and it works properly. This issue is probably just very stale, given its age and the fact that, for example, the file /examples/cpp/BUILD-CPP-EXAMPLES.md no longer exists in the tree. > Native Client examples: Build fails outside installed product directory tree > > > Key: GEODE-5736 > URL: https://issues.apache.org/jira/browse/GEODE-5736 > Project: Geode > Issue Type: Bug > Components: docs, native client >Affects Versions: 1.8.0 >Reporter: Dave Barnes >Priority: Major > Fix For: 1.12.0 > > > The file ../examples/cpp/BUILD-CPP-EXAMPLES.md (and its dotnet counterpart) > instructs the user to begin by copying the `examples` directory to the user's > own workspace. > When I do this, the Cmake configuration step fails with the following error: > > ``` > cmake .. -DGEODE_ROOT=/Users/mydir/geode16 > CMake Error at > /usr/local/Cellar/cmake/3.12.0/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 > (message): > Could NOT find GeodeNative (missing: GeodeNative_CPP_LIBRARY > GeodeNative_CPP_INCLUDE_DIR) (found version "1.0") > Call Stack (most recent call first): > > /usr/local/Cellar/cmake/3.12.0/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 > (_FPHSA_FAILURE_MESSAGE) > /Users/mydir/ncextest/examples/cmake/FindGeodeNative.cmake:116 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > continuousquery/CMakeLists.txt:28 (find_package) > ``` > When I run the same command in place in my installed `examples` directory, it > works fine. > Two solutions come to mind: > * Fix the Cmake setup, or > * Just delete this step from the BUILDING.md file (easy, but copying the > directory is really a better practice) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-5736) Native Client examples: Build fails outside installed product directory tree
[ https://issues.apache.org/jira/browse/GEODE-5736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-5736. --- > Native Client examples: Build fails outside installed product directory tree > > > Key: GEODE-5736 > URL: https://issues.apache.org/jira/browse/GEODE-5736 > Project: Geode > Issue Type: Bug > Components: docs, native client >Affects Versions: 1.8.0 >Reporter: Dave Barnes >Priority: Major > Fix For: 1.12.0 > > > The file ../examples/cpp/BUILD-CPP-EXAMPLES.md (and its dotnet counterpart) > instructs the user to begin by copying the `examples` directory to the user's > own workspace. > When I do this, the Cmake configuration step fails with the following error: > > ``` > cmake .. -DGEODE_ROOT=/Users/mydir/geode16 > CMake Error at > /usr/local/Cellar/cmake/3.12.0/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:137 > (message): > Could NOT find GeodeNative (missing: GeodeNative_CPP_LIBRARY > GeodeNative_CPP_INCLUDE_DIR) (found version "1.0") > Call Stack (most recent call first): > > /usr/local/Cellar/cmake/3.12.0/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:378 > (_FPHSA_FAILURE_MESSAGE) > /Users/mydir/ncextest/examples/cmake/FindGeodeNative.cmake:116 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > continuousquery/CMakeLists.txt:28 (find_package) > ``` > When I run the same command in place in my installed `examples` directory, it > works fine. > Two solutions come to mind: > * Fix the Cmake setup, or > * Just delete this step from the BUILDING.md file (easy, but copying the > directory is really a better practice) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reassigned GEODE-7829: - Assignee: Ernest Burghardt (was: Bruce J Schuchardt) > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Ernest Burghardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 1h > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-7829) DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51
[ https://issues.apache.org/jira/browse/GEODE-7829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce J Schuchardt reopened GEODE-7829: --- The PR changed the loss-threshold to 15 but it should be 51. It's the ack-wait-threshold that needs to be 15 > DEFAULT_ACK_WAIT_THRESHOLD inadvertently changed from 15 to 51 > -- > > Key: GEODE-7829 > URL: https://issues.apache.org/jira/browse/GEODE-7829 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce J Schuchardt >Assignee: Bruce J Schuchardt >Priority: Major > Fix For: 1.12.0, 1.13.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > During a refactor of membership code the default ack-wait-threshold was > changed from 15 to 51. This needs to be reverted and needs to be in the > 1.12.0 release. > The problem was introduced in c485cda4fc31a78892433fcb4726799b4904981f -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-5079) Investigate why dynamic_cast fails when visibility is set to 'hidden' by default in Clang
[ https://issues.apache.org/jira/browse/GEODE-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-5079. --- > Investigate why dynamic_cast fails when visibility is set to 'hidden' by > default in Clang > - > > Key: GEODE-5079 > URL: https://issues.apache.org/jira/browse/GEODE-5079 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ryan McMahon >Priority: Major > > We should investigate why symbols aren't fully exported when specifying > 'CXX_VISIBILITY_PRESET hidden' and aliasing with the 'using' keyword i.e. > ``` > using CacheableBytes = CacheableArray > ``` > The immediate fix was to set visibility to 'default' for Clang only > (https://issues.apache.org/jira/browse/GEODE-5067), but it would be good to > better understand 'hidden' visibility causes problems. > The issue can be reproduced by reverting Clang back to 'default' visibility > and running the testThinClientBigValue test. > We identified that if we do not alias with 'using' and explicitly define the > class e.g. CacheableBytes and decorate that class with APACHE_GEODE_EXPORT, > then this seems to resolve the issue when using 'hidden' by default on Clang. > However, it seems cumbersome to explicitly define all these classes just to > solve this particular issue. > Some potentially relevant stackoverflow posts include: > https://stackoverflow.com/questions/19496643/using-clang-fvisibility-hidden-and-typeinfo-and-type-erasure > [https://stackoverflow.com/questions/5116333/dynamic-cast-failed-when-hiding-symbol] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5079) Investigate why dynamic_cast fails when visibility is set to 'hidden' by default in Clang
[ https://issues.apache.org/jira/browse/GEODE-5079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-5079. - Resolution: Won't Fix Resolving won't fix - this doesn't meet the bar for investigation, because it's not an issue that's actually affecting the product at this time. We've encountered this bug in specific circumstances, and fixed it at that time against a more specific ticket describing the instance in question at that time. We'll continue to do so in the future, rather than spend developer time chasing a general solution to the problem. > Investigate why dynamic_cast fails when visibility is set to 'hidden' by > default in Clang > - > > Key: GEODE-5079 > URL: https://issues.apache.org/jira/browse/GEODE-5079 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ryan McMahon >Priority: Major > > We should investigate why symbols aren't fully exported when specifying > 'CXX_VISIBILITY_PRESET hidden' and aliasing with the 'using' keyword i.e. > ``` > using CacheableBytes = CacheableArray > ``` > The immediate fix was to set visibility to 'default' for Clang only > (https://issues.apache.org/jira/browse/GEODE-5067), but it would be good to > better understand 'hidden' visibility causes problems. > The issue can be reproduced by reverting Clang back to 'default' visibility > and running the testThinClientBigValue test. > We identified that if we do not alias with 'using' and explicitly define the > class e.g. CacheableBytes and decorate that class with APACHE_GEODE_EXPORT, > then this seems to resolve the issue when using 'hidden' by default on Clang. > However, it seems cumbersome to explicitly define all these classes just to > solve this particular issue. > Some potentially relevant stackoverflow posts include: > https://stackoverflow.com/questions/19496643/using-clang-fvisibility-hidden-and-typeinfo-and-type-erasure > [https://stackoverflow.com/questions/5116333/dynamic-cast-failed-when-hiding-symbol] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-5162) Race condition between cache destruction and background thread cache access
[ https://issues.apache.org/jira/browse/GEODE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-5162. --- > Race condition between cache destruction and background thread cache access > --- > > Key: GEODE-5162 > URL: https://issues.apache.org/jira/browse/GEODE-5162 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ryan McMahon >Priority: Major > Fix For: 1.12.0 > > > A race condition exists where the cache is accessed after it has been > destroyed in one of the many background threads created for various reasons > (failover, cleanup, periodic acks, etc). > TcrConnectionManager.startFailoverAndCleanupThreads() > ThinClientPoolHADM.startBackgroundThreads() > HostSampler.start() > There are probably other places where background threads are spun up as well, > but these are the ones that were found in our tests. > There is no synchronization between these background threads and the thread > which destroys the cache, so it is possible that the background threads > access the cache after destruction. We should investigate a robust way of > synchronizing between the thread that creates/destroys the cache and the > background threads, or evaluate if we can eliminate the dependency on the > cache in the background threads. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-5162) Race condition between cache destruction and background thread cache access
[ https://issues.apache.org/jira/browse/GEODE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-5162. - Fix Version/s: 1.12.0 Resolution: Fixed Resolving this fixed without an associated PR, because it's been addressed in several other PRs over the course of related development. In general a ticket like this needs to be written much more specifically, because it's not actually possible to know that we've fixed _all_ possible permutations of the race condition in question. It has, however, been addressed systematically, in the form of the doIfDestroyNotPending method on, I believe, CacheImpl. > Race condition between cache destruction and background thread cache access > --- > > Key: GEODE-5162 > URL: https://issues.apache.org/jira/browse/GEODE-5162 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Ryan McMahon >Priority: Major > Fix For: 1.12.0 > > > A race condition exists where the cache is accessed after it has been > destroyed in one of the many background threads created for various reasons > (failover, cleanup, periodic acks, etc). > TcrConnectionManager.startFailoverAndCleanupThreads() > ThinClientPoolHADM.startBackgroundThreads() > HostSampler.start() > There are probably other places where background threads are spun up as well, > but these are the ones that were found in our tests. > There is no synchronization between these background threads and the thread > which destroys the cache, so it is possible that the background threads > access the cache after destruction. We should investigate a robust way of > synchronizing between the thread that creates/destroys the cache and the > background threads, or evaluate if we can eliminate the dependency on the > cache in the background threads. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-6022) Make cmake 3.12 the minimum version
[ https://issues.apache.org/jira/browse/GEODE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender resolved GEODE-6022. - Fix Version/s: 1.12.0 Resolution: Fixed This has been fixed sufficiently in the two linked PRs (#399 & #402), so we'll leave it at that. > Make cmake 3.12 the minimum version > --- > > Key: GEODE-6022 > URL: https://issues.apache.org/jira/browse/GEODE-6022 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > A number of projects in the clicache now use DOTNET_TARGET_FRAMEWORK to > specify which version of the .NET framework to use. The cmake minimum should > be changed from 3.10 to 3.12 in all CMakeLists.txt files. > > Also, the BUILDING.md should also be changed accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-6022) Make cmake 3.12 the minimum version
[ https://issues.apache.org/jira/browse/GEODE-6022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Blake Bender closed GEODE-6022. --- > Make cmake 3.12 the minimum version > --- > > Key: GEODE-6022 > URL: https://issues.apache.org/jira/browse/GEODE-6022 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Michael Martell >Priority: Major > Labels: pull-request-available > Fix For: 1.12.0 > > Time Spent: 40m > Remaining Estimate: 0h > > A number of projects in the clicache now use DOTNET_TARGET_FRAMEWORK to > specify which version of the .NET framework to use. The cmake minimum should > be changed from 3.10 to 3.12 in all CMakeLists.txt files. > > Also, the BUILDING.md should also be changed accordingly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (GEODE-7562) Fix Support for JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender closed GEODE-7562.
---
> Fix Support for JSON Objects
>
>
> Key: GEODE-7562
> URL: https://issues.apache.org/jira/browse/GEODE-7562
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Fix For: 1.12.0
>
>
> As a client developer, I need to be able to put/get JSON values of different
> types.
> NC is supposed to support put/get of JSON-formatted objects using PDX and the
> class name "__GEMFIRE_JSON". For a single value of JSON, this appears to
> work properly, but if there are more than one type with this class name,
> `region::get` breaks down. The puts work, but when the values come back from
> the region the NC maps all of the values to the first type.
> For instance, the JSON object "\{ foo: 'bar' }" is put in the region with key
> 1, then the value "\{ baz: 7 }" is put with key 2. When get(key1) is called,
> you get back a PDX representation of "\{ foo: 'bar' }", but when get(key2) is
> called, instead of "\{ baz: 7}", you get back "\{ foo: }", i.e. one field,
> named foo, with no value, instead of one field named baz with value 7.
> We believe the NC is using a map for types based on class name rather than
> type ID, but are not 100% certain yet what's specifically wrong.
>
> Acceptance criteria:
> i. There is a new integration test which creates a region, puts two JSON
> values with different structures, gets them back, and compares the retrieved
> values to the originals.
> ii. Said test is passing in the standard NC integration test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-7562) Fix Support for JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-7562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Bender resolved GEODE-7562.
-
Fix Version/s: 1.12.0
Resolution: Duplicate
Dunno why this one was ignored, but there's a later issue (GEODE-7694) that was
already fixed/merged some time ago, so resolving this as a dupe of that one.
> Fix Support for JSON Objects
>
>
> Key: GEODE-7562
> URL: https://issues.apache.org/jira/browse/GEODE-7562
> Project: Geode
> Issue Type: Bug
> Components: native client
>Reporter: Michael Martell
>Priority: Major
> Fix For: 1.12.0
>
>
> As a client developer, I need to be able to put/get JSON values of different
> types.
> NC is supposed to support put/get of JSON-formatted objects using PDX and the
> class name "__GEMFIRE_JSON". For a single value of JSON, this appears to
> work properly, but if there are more than one type with this class name,
> `region::get` breaks down. The puts work, but when the values come back from
> the region the NC maps all of the values to the first type.
> For instance, the JSON object "\{ foo: 'bar' }" is put in the region with key
> 1, then the value "\{ baz: 7 }" is put with key 2. When get(key1) is called,
> you get back a PDX representation of "\{ foo: 'bar' }", but when get(key2) is
> called, instead of "\{ baz: 7}", you get back "\{ foo: }", i.e. one field,
> named foo, with no value, instead of one field named baz with value 7.
> We believe the NC is using a map for types based on class name rather than
> type ID, but are not 100% certain yet what's specifically wrong.
>
> Acceptance criteria:
> i. There is a new integration test which creates a region, puts two JSON
> values with different structures, gets them back, and compares the retrieved
> values to the originals.
> ii. Said test is passing in the standard NC integration test suite.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
