[jira] [Updated] (GEODE-3027) A developer can co-locate two keys on a put

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-3027:

Fix Version/s: (was: 1.3.0)
   1.2.0

> A developer can co-locate two keys on a put
> ---
>
> Key: GEODE-3027
> URL: https://issues.apache.org/jira/browse/GEODE-3027
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Affects Versions: 1.2.0
>Reporter: Fred Krone
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Provide a way to put co-locate two keys represented in a delimited string
> "AccountId:OrderId"
> Here ":" is the delimiter.  The String before the delimiter is the routing 
> key.  The String after the delimiter is the simple key.
> Done
> Implement PartitionResolver for delimited String keys.
> Acceptance
> A user configuring a Region with this PartitionResolver implementation gets 
> correctly delimited String keys colocated
> Keys can only be Strings or error
> Delimiter is present ":" or error
> Update JavaDocs



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-3027) A developer can co-locate two keys on a put

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-3027:
---

Assignee: Darrel Schneider

> A developer can co-locate two keys on a put
> ---
>
> Key: GEODE-3027
> URL: https://issues.apache.org/jira/browse/GEODE-3027
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, regions
>Affects Versions: 1.2.0
>Reporter: Fred Krone
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Provide a way to put co-locate two keys represented in a delimited string
> "AccountId:OrderId"
> Here ":" is the delimiter.  The String before the delimiter is the routing 
> key.  The String after the delimiter is the simple key.
> Done
> Implement PartitionResolver for delimited String keys.
> Acceptance
> A user configuring a Region with this PartitionResolver implementation gets 
> correctly delimited String keys colocated
> Keys can only be Strings or error
> Delimiter is present ":" or error
> Update JavaDocs



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2238) Member may fail to receive cluster configuration from locator

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16013287#comment-16013287
 ] 

Darrel Schneider commented on GEODE-2238:
-

Just saw the following test fail with what looks like a related issue:
{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest$$Lambda$71/1117084078.call
 in VM 0 running on Host pietas.apache.org with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:315)
at 
org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.testMetadataInClientWithFixedPartitions(FixedPRSinglehopDUnitTest.java:287)
Caused by: org.apache.geode.GemFireConfigException: cluster configuration 
service not available
at 
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:1025)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1149)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:758)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:745)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:173)
at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:166)
at 
org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.createServerWithLocator(FixedPRSinglehopDUnitTest.java:407)
at 
org.apache.geode.internal.cache.FixedPRSinglehopDUnitTest.lambda$testMetadataInClientWithFixedPartitions$e5446efe$1(FixedPRSinglehopDUnitTest.java:288)
Caused by: 
org.apache.geode.internal.process.ClusterConfigurationNotAvailableException: 
Unable to retrieve cluster configuration from the locator.
at 
org.apache.geode.internal.cache.ClusterConfigurationLoader.requestConfigurationFromLocators(ClusterConfigurationLoader.java:259)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.requestSharedConfiguration(GemFireCacheImpl.java:988)
{noformat}



> Member may fail to receive cluster configuration from locator
> -
>
> Key: GEODE-2238
> URL: https://issues.apache.org/jira/browse/GEODE-2238
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.0.0-incubating
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration
>  is failing frequently in precheckin. I'm going to mark it as FlakyTest. 
> Below is the stack trace:
> {noformat}
> :geode-lucene:distributedTest
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest
>  > indexWithAnalyzerGetsCreatedUsingClusterConfiguration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest$$Lambda$29/613305101.run
>  in VM 2 running on Host 3fb23bc375ef with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:259)
> at org.apache.geode.test.dunit.rules.Member.invoke(Member.java:60)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.indexWithAnalyzerGetsCreatedUsingClusterConfiguration(LuceneClusterConfigurationDUnitTest.java:102)
> Caused by:
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at org.junit.Assert.assertNotNull(Assert.java:722)
> at 
> org.apache.geode.cache.lucene.internal.configuration.LuceneClusterConfigurationDUnitTest.lambda$indexWithAnalyzerGetsCreatedUsingClusterConfiguration$bb17a952$1(LuceneClusterConfigurationDUnitTest.java:105)
> 94 tests completed, 1 failed
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2904) PRTXJUnitTest testEntryNotFound failing intermittently

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2904.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

This issue has already been fixed by changes to the LonerDistributionManager 
thread pool.


> PRTXJUnitTest testEntryNotFound failing intermittently
> --
>
> Key: GEODE-2904
> URL: https://issues.apache.org/jira/browse/GEODE-2904
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
> Fix For: 1.2.0
>
>
> org.apache.geode.internal.cache.PRTXJUnitTest > testEntryNotFound FAILED
> java.util.concurrent.RejectedExecutionException: Task 
> org.apache.geode.internal.cache.BucketAdvisor$VolunteeringDelegate$2@4a31a107 
> rejected from java.util.concurrent.ThreadPoolExecutor@68710006[Terminated, 
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 1]



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2903) FreeListOffHeapRegionJUnitTest testLocalPersistentCompressed failing intermittently

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2903.
-
   Resolution: Duplicate
Fix Version/s: 1.2.0

> FreeListOffHeapRegionJUnitTest testLocalPersistentCompressed failing 
> intermittently
> ---
>
> Key: GEODE-2903
> URL: https://issues.apache.org/jira/browse/GEODE-2903
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest > 
> testLocalPersistentCompressed FAILED
> java.lang.AssertionError: expected:<0> but was:<24>
> org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
> testLocalPersistentCompressed FAILED
> java.lang.AssertionError: expected:<0> but was:<48>



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2903) FreeListOffHeapRegionJUnitTest testLocalPersistentCompressed failing intermittently

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2903:
---

Assignee: Darrel Schneider

> FreeListOffHeapRegionJUnitTest testLocalPersistentCompressed failing 
> intermittently
> ---
>
> Key: GEODE-2903
> URL: https://issues.apache.org/jira/browse/GEODE-2903
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest > 
> testLocalPersistentCompressed FAILED
> java.lang.AssertionError: expected:<0> but was:<24>
> org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
> testLocalPersistentCompressed FAILED
> java.lang.AssertionError: expected:<0> but was:<48>



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2902) OffHeapLRURecoveryRegressionTest recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory fails intermittently

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2902:
---

Assignee: Darrel Schneider

> OffHeapLRURecoveryRegressionTest 
> recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory fails intermittently
> ---
>
> Key: GEODE-2902
> URL: https://issues.apache.org/jira/browse/GEODE-2902
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> org.apache.geode.internal.offheap.OffHeapLRURecoveryRegressionTest > 
> recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory FAILED
> java.lang.AssertionError: expected:<10> but was:<11>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.internal.offheap.OffHeapLRURecoveryRegressionTest.recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory(OffHeapLRURecoveryRegressionTest.java:74)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2895) CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2895.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent
> -
>
> Key: GEODE-2895
> URL: https://issues.apache.org/jira/browse/GEODE-2895
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Lynn Gallinat
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
> testLocalPersistent FAILED
> java.lang.AssertionError: expected:<0> but was:<24>
> java.lang.AssertionError: expected:<0> but was:<24>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:451)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:211)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.testLocalPersistent(OffHeapRegionBase.java:618)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> 

[jira] [Assigned] (GEODE-2895) CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2895:
---

Assignee: Darrel Schneider

> CI failure: OldFreeListOffHeapRegionJUnitTest.testLocalPersistent
> -
>
> Key: GEODE-2895
> URL: https://issues.apache.org/jira/browse/GEODE-2895
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Lynn Gallinat
>Assignee: Darrel Schneider
>
> {noformat}
> org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
> testLocalPersistent FAILED
> java.lang.AssertionError: expected:<0> but was:<24>
> java.lang.AssertionError: expected:<0> but was:<24>
>   at org.junit.Assert.fail(Assert.java:88)
>   at org.junit.Assert.failNotEquals(Assert.java:834)
>   at org.junit.Assert.assertEquals(Assert.java:645)
>   at org.junit.Assert.assertEquals(Assert.java:631)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:451)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.doRegionTest(OffHeapRegionBase.java:211)
>   at 
> org.apache.geode.internal.offheap.OffHeapRegionBase.testLocalPersistent(OffHeapRegionBase.java:618)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> 

[jira] [Created] (GEODE-2903) FreeListOffHeapRegionJUnitTest testLocalPersistentCompressed failing intermittently

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2903:
---

 Summary: FreeListOffHeapRegionJUnitTest 
testLocalPersistentCompressed failing intermittently
 Key: GEODE-2903
 URL: https://issues.apache.org/jira/browse/GEODE-2903
 Project: Geode
  Issue Type: Bug
  Components: offheap
Reporter: Darrel Schneider


org.apache.geode.internal.offheap.FreeListOffHeapRegionJUnitTest > 
testLocalPersistentCompressed FAILED
java.lang.AssertionError: expected:<0> but was:<24>

org.apache.geode.internal.offheap.OldFreeListOffHeapRegionJUnitTest > 
testLocalPersistentCompressed FAILED
java.lang.AssertionError: expected:<0> but was:<48>




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2902) OffHeapLRURecoveryRegressionTest recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory fails intermittently

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2902:
---

 Summary: OffHeapLRURecoveryRegressionTest 
recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory fails intermittently
 Key: GEODE-2902
 URL: https://issues.apache.org/jira/browse/GEODE-2902
 Project: Geode
  Issue Type: Bug
  Components: offheap
Reporter: Darrel Schneider


org.apache.geode.internal.offheap.OffHeapLRURecoveryRegressionTest > 
recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory FAILED
java.lang.AssertionError: expected:<10> but was:<11>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.geode.internal.offheap.OffHeapLRURecoveryRegressionTest.recoveringTooMuchDataDoesNotRunOutOfOffHeapMemory(OffHeapLRURecoveryRegressionTest.java:74)




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-236) Remove deprecated CacheEvent methods

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-236.

   Resolution: Fixed
Fix Version/s: 1.2.0

> Remove deprecated CacheEvent methods
> 
>
> Key: GEODE-236
> URL: https://issues.apache.org/jira/browse/GEODE-236
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following methods need to be removed:
> - CacheEvent.isExpiration: change to CacheEvent.getOperation().isExpiration
> - CacheEvent.isDistributed: change to CacheEvent.getOperation().isDistributed
> This should be a pretty easy task to complete.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-236) Remove deprecated CacheEvent methods

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-236:
--

Assignee: Darrel Schneider  (was: Avinash Dongre)

> Remove deprecated CacheEvent methods
> 
>
> Key: GEODE-236
> URL: https://issues.apache.org/jira/browse/GEODE-236
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following methods need to be removed:
> - CacheEvent.isExpiration: change to CacheEvent.getOperation().isExpiration
> - CacheEvent.isDistributed: change to CacheEvent.getOperation().isDistributed
> This should be a pretty easy task to complete.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-236) Remove deprecated CacheEvent methods

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003249#comment-16003249
 ] 

Darrel Schneider commented on GEODE-236:


The previous fix introduced these javadocs warnings. I will check in a fix for 
these soon:
{noformat}
:geode-core:javadoc/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:193:
 warning - Tag @see: can't find isExpiration() in 
org.apache.geode.cache.CacheEvent
/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:200:
 warning - Tag @see: can't find isDistributed() in 
org.apache.geode.cache.CacheEvent

{noformat}



> Remove deprecated CacheEvent methods
> 
>
> Key: GEODE-236
> URL: https://issues.apache.org/jira/browse/GEODE-236
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following methods need to be removed:
> - CacheEvent.isExpiration: change to CacheEvent.getOperation().isExpiration
> - CacheEvent.isDistributed: change to CacheEvent.getOperation().isDistributed
> This should be a pretty easy task to complete.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-237) Remove EntryEvent deprecated methods

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-237:
--

Assignee: Avinash Dongre  (was: Darrel Schneider)

> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (GEODE-237) Remove EntryEvent deprecated methods

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-237:
---
Comment: was deleted

(was: The previous fix introduced these javadocs warnings. I will check in a 
fix for these soon:
{noformat}
:geode-core:javadoc/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:193:
 warning - Tag @see: can't find isExpiration() in 
org.apache.geode.cache.CacheEvent
/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:200:
 warning - Tag @see: can't find isDistributed() in 
org.apache.geode.cache.CacheEvent

{noformat}

)

> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-237) Remove EntryEvent deprecated methods

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003236#comment-16003236
 ] 

Darrel Schneider commented on GEODE-237:


The previous fix introduced these javadocs warnings. I will check in a fix for 
these soon:
{noformat}
:geode-core:javadoc/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:193:
 warning - Tag @see: can't find isExpiration() in 
org.apache.geode.cache.CacheEvent
/tmp/gemfire-build/geode/geode-core/src/main/java/org/apache/geode/internal/cache/RegionEventImpl.java:200:
 warning - Tag @see: can't find isDistributed() in 
org.apache.geode.cache.CacheEvent

{noformat}



> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-237) Remove EntryEvent deprecated methods

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-237:
--

Assignee: Darrel Schneider  (was: Avinash Dongre)

> Remove EntryEvent deprecated methods
> 
>
> Key: GEODE-237
> URL: https://issues.apache.org/jira/browse/GEODE-237
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> The following EntryEvent methods need to be removed:
> - isLocalLoad: change to getOperation().isLocalLoad
> - isNetLoad: change to getOperation().isNetLoad
> - isLoad: change to getOperation().isLoad
> - isNetSearch: change to getOperation().isNetSearch
> - isBridgeEvent: change to hasClientOrigin
> these should be pretty easy to change



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2894) Review getEntry on Region

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16003171#comment-16003171
 ] 

Darrel Schneider commented on GEODE-2894:
-

Another key different between get and getEntry is that getEntry will never call 
a CacheLoader.


> Review getEntry on Region
> -
>
> Key: GEODE-2894
> URL: https://issues.apache.org/jira/browse/GEODE-2894
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> This needs to behave the same as .get()
> For example, on a RegionAttributeShortcut.PROXY
> .put will put on the server ... 
> but currently .entry is local only and will return null 
> .get will go to the server and get the value
> ACCEPTANCE
> WHEN Region.put(Object o) is used Region.get or Region.getEntry should return 
> as .get would



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2894) Review getEntry on Region

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16001822#comment-16001822
 ] 

Darrel Schneider commented on GEODE-2894:
-

Except for partitioned regions getEntry always returns a Region.Entry the 
describes the local, in process, cache state.
Region.Entry has an "isLocal" method with these javadocs:
{noformat}
/**
 * This method checks to see if the entry is in the in-process cache, or is 
in another process.
 * Only Regions with {@link DataPolicy#PARTITION} may return false in 
response to this query. A
 * non-local Entry will not reflect dynamic changes being made to the 
cache. For instance, the
 * result of getValue() will not change, even though the cache may have 
been updated for the
 * corresponding key. To see an updated snapshot of a non-local Entry, you 
must fetch the entry
 * from the Region again.
 */
public boolean isLocal();
{noformat}

> Review getEntry on Region
> -
>
> Key: GEODE-2894
> URL: https://issues.apache.org/jira/browse/GEODE-2894
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> This needs to behave the same as .get()
> For example, on a RegionAttributeShortcut.PROXY
> .put will put on the server ... 
> but currently .entry is local only and will return null 
> .get will go to the server and get the value
> ACCEPTANCE
> WHEN Region.put(Object o) is used Region.get or Region.getEntry should return 
> as .get would



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (GEODE-1887) Client PROXY region should delegate all operations to server

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider edited comment on GEODE-1887 at 5/5/17 6:52 PM:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
# the region state in the client space
# the region state in the server space

The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.



was (Author: dschneider):
The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  

[jira] [Comment Edited] (GEODE-1887) Client PROXY region should delegate all operations to server

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider edited comment on GEODE-1887 at 5/5/17 6:52 PM:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
*  public RegionAttributes getAttributes();
*  public AttributesMutator getAttributesMutator();
*  public CacheStatistics getStatistics();
*  public Entry getEntry(Object key);
*  public  Region getSubregion(String path);
*  public Set subregions(boolean recursive);
*  public Set keySet();
*  public Collection values();
*  public Set entrySet(boolean recursive);
*  public Set> entrySet();
*  public Object getUserAttribute();
*  public void setUserAttribute(Object value);
*  public boolean isDestroyed();
*  public boolean containsValueForKey(Object key);
*  public boolean containsKey(Object key);
*  public boolean containsValue(Object value);
*  public boolean isEmpty();
*  public int size();
*  default void forEach(BiConsumer action)
*  default void replaceAll(BiFunction 
function)


Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.



was (Author: dschneider):
The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
  public RegionAttributes getAttributes();
  public AttributesMutator getAttributesMutator();
  public CacheStatistics getStatistics();
  public Entry getEntry(Object key);
  public  Region getSubregion(String path);
  public Set subregions(boolean recursive);
  public Set keySet();
  public Collection values();
  public Set entrySet(boolean recursive);
  public Set> entrySet();
  public Object getUserAttribute();
  public void setUserAttribute(Object value);
  public boolean isDestroyed();
  public boolean containsValueForKey(Object key);
  public boolean containsKey(Object key);
  public boolean containsValue(Object value);
  public boolean isEmpty();
  public int size();
  default void forEach(BiConsumer action)
  default void replaceAll(BiFunction 
function)

Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 

[jira] [Commented] (GEODE-1887) Client PROXY region should delegate all operations to server

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15998776#comment-15998776
 ] 

Darrel Schneider commented on GEODE-1887:
-

The problem with changing the existing behavior of PROXY on a client is that it 
could break existing applications.
When Region methods are done on a client region then it must always decide what 
it will do with two possible spaces:
  1. the region state in the client space
  2. the region state in the server space
The following region methods limit themselves to the client space:
  public RegionAttributes getAttributes();
  public AttributesMutator getAttributesMutator();
  public CacheStatistics getStatistics();
  public Entry getEntry(Object key);
  public  Region getSubregion(String path);
  public Set subregions(boolean recursive);
  public Set keySet();
  public Collection values();
  public Set entrySet(boolean recursive);
  public Set> entrySet();
  public Object getUserAttribute();
  public void setUserAttribute(Object value);
  public boolean isDestroyed();
  public boolean containsValueForKey(Object key);
  public boolean containsKey(Object key);
  public boolean containsValue(Object value);
  public boolean isEmpty();
  public int size();
  default void forEach(BiConsumer action)
  default void replaceAll(BiFunction 
function)

Some of these (keySet and containsKey) already have corresponding methods that 
perform the same operation in the server space (keySetOnServer and 
containsKeyOnServer).
For at least some of the other client space methods I think we should also add 
"OnServer" methods. For example "sizeOnServer" and "isEmptyOnServer". I think 
it is easier for a develop to discover the "OnServer" method and it also tells 
them that a client has two different ways of answering the size question. These 
"OnServer" methods will fail with an UnsupportedOperationException if called on 
a non-client region. They will also completely ignore any client state. For 
example sizeOnServer will not consider any entries cached in the client but 
will simply report the size from the server's point of view.


> Client PROXY region should delegate all operations to server
> 
>
> Key: GEODE-1887
> URL: https://issues.apache.org/jira/browse/GEODE-1887
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>Assignee: Avinash Dongre
>
> Currently a ClientRegionShortcut.PROXY region sends operations like put() and 
> get() over to the server, but for operations like size() and isEmpty() it 
> just consults the local state on the client  and returns 0 and true 
> respectively, even though there may be data in the servers for that region.
> A PROXY region should not attempt to consult its local state for any 
> operation. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2864.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Trivial
> Fix For: 1.2.0
>
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2676:

Component/s: management

> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Fred Krone
>Priority: Minor
>  Labels: jmx
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and 
> lastModifiedTime will always be 0 for an mbean that represents an partitioned 
> region.
> The gettors for these methods may call getStatistics() which on a PR always 
> throws UnsupportedOperationException. So this exception might even get 
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which 
> returns true on a PartitionedRegion. This does have meaning on a PR but it 
> does not mean that getStatistics() is a supported operation. On a PR setting 
> statistics-enabled causes each region-entry to also keep track of its last 
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call 
> getStatistics. But the opposite is not true. Since we currently have regions 
> that do not support getStatistics(), the code in RegionMBeanBridge should 
> catch UnsupportedOperationException and handle it. I would suggest that the 
> constructor be changed that initializes the "isStatisticsEnabled" field. 
> Instead of only calling getStatisticsEnabled() it should also call 
> getStatistics(). Something like this:
> {noformat}
> {
>   boolean useGetStatistics = regAttrs.getStatisticsEnabled();
>   if (useGetStatistics) {
> try {
>   region.getStatistics();
> } catch (UnsupportedOperationException ex) {
>   useGetStatistics = false;
> }
>   }
>   this.isStatisticsEnabled = useGetStatistics;
> }
> {noformat}
> That way in a future release if PRs are changed to support getStatistics this 
> code will start calling it without having a direct dependency on the 
> implementation of PartitionedRegion.
> https://issues.apache.org/jira/browse/GEODE-2685 is a request to support 
> getStatistics on PRs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2864:

Priority: Trivial  (was: Major)

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Trivial
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2864:
---

Assignee: Darrel Schneider

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2864:

Affects Version/s: 1.0.0-incubating

> In same cases committing a geode transaction logs a meaningless warning
> ---
>
> Key: GEODE-2864
> URL: https://issues.apache.org/jira/browse/GEODE-2864
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Sometimes a transaction commit will log a warning message that looks like 
> this:
> {code}
> [warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  port 40405 Thread 0> tid=0x59] New members for Region: 
> com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
>  concurrencyChecksEnabled] orig list: 
> [pivhdsne(GemfireAPIServer1:79899):1265] new list: 
> [pivhdsne(GemfireAPIServer4:80172):56801, 
> pivhdsne(GemfireAPIServer1:79899):1265, 
> pivhdsne(GemfireAPIServer3:80078):14603]
> {code}
> This warning can be safely ignored.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2864) In same cases committing a geode transaction logs a meaningless warning

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2864:
---

 Summary: In same cases committing a geode transaction logs a 
meaningless warning
 Key: GEODE-2864
 URL: https://issues.apache.org/jira/browse/GEODE-2864
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Darrel Schneider


Sometimes a transaction commit will log a warning message that looks like this:
{code}
[warning 2017/04/27 17:11:15.034 CST GemfireAPIServer2  tid=0x59] New members for Region: 
com.gemstone.gemfire.internal.cache.DistributedRegion[path='/exampleRegionRep1';scope=DISTRIBUTED_ACK';dataPolicy=REPLICATE;
 concurrencyChecksEnabled] orig list: 
[pivhdsne(GemfireAPIServer1:79899):1265] new list: 
[pivhdsne(GemfireAPIServer4:80172):56801, 
pivhdsne(GemfireAPIServer1:79899):1265, 
pivhdsne(GemfireAPIServer3:80078):14603]
{code}

This warning can be safely ignored.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2862) shutdown hook does not wait for disk store async tasks to complete

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2862:

Affects Version/s: 1.0.0-incubating

> shutdown hook does not wait for disk store async tasks to complete
> --
>
> Key: GEODE-2862
> URL: https://issues.apache.org/jira/browse/GEODE-2862
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>
> If you do a normal cache close and are using persistence then each disk store 
> close will wait for all of its async background tasks to complete.
> But if instead the JVM shutdown hook is used (see 
> java.lang.Runtime.addShutdownHook(Thread) for a description of what causes 
> the shutdown hook to be called) then it will not wait for the async 
> persistent tasks to complete.
> Both of these types of shutdown are considered an orderly shutdown (as 
> opposed to a unorderly shutdown caused by things like a kill -9) and geode 
> should only have one type of orderly shutdown. By not waiting for the async 
> persistent tasks to complete some files may never be fully written.
> Here is the code that causes the shutdown hook to not wait in DiskStoreImpl:
> {code}
>   // don't block the shutdown hook
>   if (Thread.currentThread() != InternalDistributedSystem.shutdownHook) {
> waitForBackgroundTasks();
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2861:

Affects Version/s: 1.0.0-incubating

> remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool
> ---
>
> Key: GEODE-2861
> URL: https://issues.apache.org/jira/browse/GEODE-2861
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Affects Versions: 1.0.0-incubating
>Reporter: Darrel Schneider
>Priority: Trivial
>
> Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting 
> down the DiskStoreTaskPool.
> On DiskStoreImpl see these methods:
>   stopDiskStoreTaskPool
>   shutdownPool
> On GemFireCacheImpl the field diskStoreTaskPool is always null.
> Note that a bug exists in this deadcode that causes it to not call 
> taskCancelled as it iterates over a list of runnables. Since this code is 
> dead it is currently doing no harm but if the code is not removed then make 
> sure and fix this loop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2863) DiskStoreImpl close does not shutdown its thread pools

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2863:
---

 Summary: DiskStoreImpl close does not shutdown its thread pools
 Key: GEODE-2863
 URL: https://issues.apache.org/jira/browse/GEODE-2863
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


Closing a DiskStoreImpl does not shutdown its thread pools.
It has two pools, "diskStoreTaskPool" and "delayedWritePool", that it does not 
shutdown.
However at least in some cases (see GEODE-2862) it does wait for all the tasks 
submitted to these pools to complete. But it is not clear if additional tasks 
could still be submitted after this wait is done.
Some logic should be added that causes the code that would submit a task to 
these executors to no longer do so or, if needed, to process the task inline.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2862) shutdown hook does not wait for disk store async tasks to complete

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2862:
---

 Summary: shutdown hook does not wait for disk store async tasks to 
complete
 Key: GEODE-2862
 URL: https://issues.apache.org/jira/browse/GEODE-2862
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


If you do a normal cache close and are using persistence then each disk store 
close will wait for all of its async background tasks to complete.
But if instead the JVM shutdown hook is used (see 
java.lang.Runtime.addShutdownHook(Thread) for a description of what causes the 
shutdown hook to be called) then it will not wait for the async persistent 
tasks to complete.

Both of these types of shutdown are considered an orderly shutdown (as opposed 
to a unorderly shutdown caused by things like a kill -9) and geode should only 
have one type of orderly shutdown. By not waiting for the async persistent 
tasks to complete some files may never be fully written.

Here is the code that causes the shutdown hook to not wait in DiskStoreImpl:
{code}
  // don't block the shutdown hook
  if (Thread.currentThread() != InternalDistributedSystem.shutdownHook) {
waitForBackgroundTasks();
  }
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2861:
---

 Summary: remove deadcode in GemFireCacheImpl and DiskStoreImpl for 
DiskStoreTaskPool
 Key: GEODE-2861
 URL: https://issues.apache.org/jira/browse/GEODE-2861
 Project: Geode
  Issue Type: Improvement
  Components: persistence
Reporter: Darrel Schneider


Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting down 
the DiskStoreTaskPool.

On DiskStoreImpl see these methods:
  stopDiskStoreTaskPool
  shutdownPool
On GemFireCacheImpl the field diskStoreTaskPool is always null.

Note that a bug exists in this deadcode that causes it to not call 
taskCancelled as it iterates over a list of runnables. Since this code is dead 
it is currently doing no harm but if the code is not removed then make sure and 
fix this loop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2861) remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2861:

Priority: Trivial  (was: Major)

> remove deadcode in GemFireCacheImpl and DiskStoreImpl for DiskStoreTaskPool
> ---
>
> Key: GEODE-2861
> URL: https://issues.apache.org/jira/browse/GEODE-2861
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Darrel Schneider
>Priority: Trivial
>
> Both GemFireCacheImpl and DiskStoreImpl have deadcode related to shutting 
> down the DiskStoreTaskPool.
> On DiskStoreImpl see these methods:
>   stopDiskStoreTaskPool
>   shutdownPool
> On GemFireCacheImpl the field diskStoreTaskPool is always null.
> Note that a bug exists in this deadcode that causes it to not call 
> taskCancelled as it iterates over a list of runnables. Since this code is 
> dead it is currently doing no harm but if the code is not removed then make 
> sure and fix this loop.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2860) refactor EventTracker to be on DistributedRegion instead of LocalRegion

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2860:
---

 Summary: refactor EventTracker to be on DistributedRegion instead 
of LocalRegion
 Key: GEODE-2860
 URL: https://issues.apache.org/jira/browse/GEODE-2860
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


Currently LocalRegion has a non-final field named "eventTracker". It is 
initialized in a method named createEventTracker which does nothing on 
LocalRegion but is implemented on DistributedRegion and BucketRegion to 
initialize the eventTracker field.

I think things would be clearer if this field was moved to DistributedRegion.
All the code on LocalRegion that currently tests for a non-null eventTracker 
can be changed to do nothing and overridden on DistributedRegion to use its 
eventTracker. DistributedRegion can make this field final and always set it in 
its constructor. Since BucketRegion extends DistributedRegion it does not to do 
anything (it currently implements createEventTracker but that was not needed 
since it inherits the same impl from DistributedRegion).




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2841) unable to create off-heap region from cache.xml

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2841:

Component/s: (was: offheap)
 management

> unable to create off-heap region from cache.xml
> ---
>
> Key: GEODE-2841
> URL: https://issues.apache.org/jira/browse/GEODE-2841
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Swapnil Bawaskar
>
> I defined a cache.xml as follows:
> {noformat}
> 
>  xmlns="http://geode.apache.org/schema/cache;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
> xsi:schemaLocation="http://geode.apache.org/schema/cache 
> http://geode.apache.org/schema/cache/cache-1.0.xsd;
> version="1.0">
>   
>   
>   
>
> 
> {noformat}
> But, this region is not configured for off-heap:
> {noformat}
> gfsh>describe region --name=/regionA
> ..
> Name: regionA
> Data Policy : partition
> Hosting Members : serv1
> Non-Default Attributes Shared By Hosting Members
>  Type  |Name | Value
> -- | --- | -
> Region | size| 0
>| data-policy | PARTITION
> {noformat}
> When the region is created from gfsh
> {noformat}
> gfsh>create region --name=regionB --type=PARTITION --off-heap
> {noformat}
> The region is configured for off-heap
> {noformat}
> gfsh>describe region --name=/regionB
> ..
> Name: regionB
> Data Policy : partition
> Hosting Members : serv1
> Non-Default Attributes Shared By Hosting Members
>   Type|   Name   | Value
> - |  | -
> Region| data-policy  | PARTITION
>   | size | 0
>   | off-heap | true
> Partition | local-max-memory | 3276
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2845) Clients need Region to have views of local and server regions for consistency checks

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15989574#comment-15989574
 ] 

Darrel Schneider commented on GEODE-2845:
-

Another option would be to add more "OnServer" methods to Region. We already 
have "keySet" and "keySetOnServer".
So for other methods that currently limit themselves to the local data we could 
add "OnServer" flavors. For example "sizeOnServer".
Given a proxy region named "r" I think doing this:
  r.sizeOnServer();
is easier than this:
  r.getServerView().size();
At least one advantage of having  "OnServer" variants of the methods is that 
when you are in your IDE and start typing "siz..." you will see two options. 
This might help you to stop and think about which size you want.


> Clients need Region to have views of local and server regions for consistency 
> checks
> 
>
> Key: GEODE-2845
> URL: https://issues.apache.org/jira/browse/GEODE-2845
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Fred Krone
>Assignee: Darrel Schneider
>
> Example: 
> CacheStatistics ... Region.getLocalCacheStatistics()
> CacheStatistics ... Region.getServerCacheStatistics()
> Or Region.getLocalView() and Region.getServerView()
> For Caching_Proxy would have a local view   PROXY regions it would be null or 
> empty.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2786) CI failure: DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2786:

Component/s: (was: persistence)
 management

> CI failure: 
> DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen
> --
>
> Key: GEODE-2786
> URL: https://issues.apache.org/jira/browse/GEODE-2786
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Lynn Gallinat
>  Labels: CI
>
> Failed in concourse GemFireIntegrationTest #706
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest > 
> aboveZeroDeletesPreviousFiles_nameWithHyphen FAILED
> org.junit.ComparisonFailure: [Unexpected files: 
> [/tmp/junit88809687228487/psin8p724_cache1-statistics-02-01.gfs, 
> /tmp/junit88809687228487/psin8p724_cache1-statistics-02-02.gfs, 
> /tmp/junit88809687228487/psin8p724_cache1-statistics.gfs]] expected:<[2]> 
> but was:<[3]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native 
> Method)
> at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.validateNumberFiles(DiskSpaceLimitIntegrationTest.java:263)
> at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles_nameWithHyphen(DiskSpaceLimitIntegrationTest.java:251)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2811:

Affects Version/s: 1.0.0-incubating
   1.1.0
   1.1.1

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2811.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2801) disk store backup can fail with ArrayIndexOutOfBoundsException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2801.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> disk store backup can fail with ArrayIndexOutOfBoundsException
> --
>
> Key: GEODE-2801
> URL: https://issues.apache.org/jira/browse/GEODE-2801
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> A race condition exists in which a disk store backup may fail with an 
> ArrayIndexOutOfBoundsException when calling hasKrf. Here is an example call 
> stack:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 24
> at 
> it.unimi.dsi.fastutil.longs.LongOpenHashSet.contains(LongOpenHashSet.java:315)
> at 
> org.apache.geode.internal.cache.DiskInitFile.hasKrf(DiskInitFile.java:814)
> at org.apache.geode.internal.cache.Oplog.copyTo(Oplog.java:5724)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.finishBackup(DiskStoreImpl.java:4218)
> at 
> org.apache.geode.internal.cache.persistence.BackupManager.finishBackup(BackupManager.java:206)
> at 
> org.apache.geode.admin.internal.FinishBackupRequest.createResponse(FinishBackupRequest.java:101)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2109) calling submit on ExecutionService can cause exceptions to be lost

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983799#comment-15983799
 ] 

Darrel Schneider commented on GEODE-2109:
-

I found some additional calls to "submit" in HeapEvictor and will be changing 
them to "execute" as part of the fix for GEODE-2811

> calling submit on ExecutionService can cause exceptions to be lost
> --
>
> Key: GEODE-2109
> URL: https://issues.apache.org/jira/browse/GEODE-2109
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
> Fix For: 1.1.0
>
>
> Geode has a number of places that call submit on ExecutionService. The submit 
> method returns a Future object. If the caller makes sure it calls "get" on 
> the Future then all is well. But in many places geode is not calling get. In 
> that case if the Runnable that was submitted throws an exception it gets 
> stored in the get and never logged. This can make it very hard to diagnose 
> problems.
> If the caller does not want to call get on the returned Future then it should 
> instead call the "execute" method. In that case the exception will be 
> unhandled and the unhandled exception handler code we have on the 
> LoggingThreadGroup class will cause the exception to be logged.
> Here are the places that should be changed to use execute instead of submit:
> org.apache.geode.internal.util.concurrent.CustomEntryConcurrentHashMap.clear()
> org.apache.geode.internal.cache.DiskStoreImpl.executeDiskStoreTask(Runnable)
> org.apache.geode.internal.cache.lru.HeapEvictor.onEvent(MemoryEvent)
> org.apache.geode.distributed.internal.InternalLocator.restartWithDS(InternalDistributedSystem,
>  GemFireCacheImpl)
> org.apache.geode.distributed.internal.FunctionExecutionPooledExecutor.FunctionExecutionPooledExecutor(BlockingQueue,
>  int, PoolStatHelper, ThreadFactory, int, boolean)
> org.apache.geode.internal.cache.PRHARedundancyProvider.scheduleCreateMissingBuckets()
> org.apache.geode.distributed.internal.InternalLocator.startSharedConfigurationService(GemFireCacheImpl)
> org.apache.geode.cache.client.internal.SingleHopClientExecutor.submitTask(Runnable)
> org.apache.geode.management.internal.FederatingManager.submitTask(Callable)



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2097.
-
Resolution: Fixed

> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2811:
---

Assignee: Darrel Schneider

> Thread leak when offheap memory is configured
> -
>
> Key: GEODE-2811
> URL: https://issues.apache.org/jira/browse/GEODE-2811
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> If you are using offheap memory and keep creating and close the cache over 
> and over then you may run out of threads.
> Each time the cache is initialized it creates a thread pool to handle offheap 
> LRU eviction. The thread pool should be closed when the cache is closed but 
> is not.
> The can lead to an exception like this:
> {quote}
> java.lang.OutOfMemoryError: unable to create new native thread
> {quote}
> The threads will be cleaned up if the garbage collector has a major enough 
> collection to force java object finalization but that may never happen since 
> offheap is being used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2811) Thread leak when offheap memory is configured

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2811:
---

 Summary: Thread leak when offheap memory is configured
 Key: GEODE-2811
 URL: https://issues.apache.org/jira/browse/GEODE-2811
 Project: Geode
  Issue Type: Bug
  Components: offheap
Reporter: Darrel Schneider


If you are using offheap memory and keep creating and close the cache over and 
over then you may run out of threads.
Each time the cache is initialized it creates a thread pool to handle offheap 
LRU eviction. The thread pool should be closed when the cache is closed but is 
not.

The can lead to an exception like this:
{quote}
java.lang.OutOfMemoryError: unable to create new native thread
{quote}
The threads will be cleaned up if the garbage collector has a major enough 
collection to force java object finalization but that may never happen since 
offheap is being used.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reopened GEODE-2097:
-

the unit test introduced in this fix if failing intermittently.

> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2805) disk store backup may not include krf files for the oplogs it backs up

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2805:
---

 Summary: disk store backup may not include krf files for the 
oplogs it backs up
 Key: GEODE-2805
 URL: https://issues.apache.org/jira/browse/GEODE-2805
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


I believe a race condition exists that will cause a disk store backup to not 
backup one or more krf files for the oplogs it backs up. You can still restore 
from this backup but the recovery may go much slower.

Backup should be changed to wait for the async krf creation to complete instead 
of skipping over that krf file. I think this can be done in Oplog.java at the 
spot it currently calls "hasKrf". I think that if it instead first called 
"finishKrf" that it would wait for an in-progress krf creation to finish.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2801) disk store backup can fail with ArrayIndexOutOfBoundsException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2801:
---

Assignee: Darrel Schneider

> disk store backup can fail with ArrayIndexOutOfBoundsException
> --
>
> Key: GEODE-2801
> URL: https://issues.apache.org/jira/browse/GEODE-2801
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> A race condition exists in which a disk store backup may fail with an 
> ArrayIndexOutOfBoundsException when calling hasKrf. Here is an example call 
> stack:
> {code}
> java.lang.ArrayIndexOutOfBoundsException: 24
> at 
> it.unimi.dsi.fastutil.longs.LongOpenHashSet.contains(LongOpenHashSet.java:315)
> at 
> org.apache.geode.internal.cache.DiskInitFile.hasKrf(DiskInitFile.java:814)
> at org.apache.geode.internal.cache.Oplog.copyTo(Oplog.java:5724)
> at 
> org.apache.geode.internal.cache.DiskStoreImpl.finishBackup(DiskStoreImpl.java:4218)
> at 
> org.apache.geode.internal.cache.persistence.BackupManager.finishBackup(BackupManager.java:206)
> at 
> org.apache.geode.admin.internal.FinishBackupRequest.createResponse(FinishBackupRequest.java:101)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2801) disk store backup can fail with ArrayIndexOutOfBoundsException

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2801:
---

 Summary: disk store backup can fail with 
ArrayIndexOutOfBoundsException
 Key: GEODE-2801
 URL: https://issues.apache.org/jira/browse/GEODE-2801
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


A race condition exists in which a disk store backup may fail with an 
ArrayIndexOutOfBoundsException when calling hasKrf. Here is an example call 
stack:
{code}
java.lang.ArrayIndexOutOfBoundsException: 24
at 
it.unimi.dsi.fastutil.longs.LongOpenHashSet.contains(LongOpenHashSet.java:315)
at 
org.apache.geode.internal.cache.DiskInitFile.hasKrf(DiskInitFile.java:814)
at org.apache.geode.internal.cache.Oplog.copyTo(Oplog.java:5724)
at 
org.apache.geode.internal.cache.DiskStoreImpl.finishBackup(DiskStoreImpl.java:4218)
at 
org.apache.geode.internal.cache.persistence.BackupManager.finishBackup(BackupManager.java:206)
at 
org.apache.geode.admin.internal.FinishBackupRequest.createResponse(FinishBackupRequest.java:101)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2792) Server has concurrencyChecksEnabled log message has the booleans switched

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2792.
-
Resolution: Not A Problem

I thought this method was called the server.
But it is actually only called on a client when the server pushes messages to 
the client through the subscription queue.

So I am going to resolve this ticked as not being a problem.


> Server has concurrencyChecksEnabled log message has the booleans switched
> -
>
> Key: GEODE-2792
> URL: https://issues.apache.org/jira/browse/GEODE-2792
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Priority: Trivial
>
> The log message: "Server has concurrencyChecksEnabled {0} but client has {1}" 
> should instead be:  "Server has concurrencyChecksEnabled {1} but client has 
> {0}".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2792) Server has concurrencyChecksEnabled log message has the booleans switched

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15971876#comment-15971876
 ] 

Darrel Schneider commented on GEODE-2792:
-

Here is a refactoring of the code that would fix this:
{code}
  private void concurrencyConfigurationCheck(VersionTag tag) {
if (this.concurrencyMessageIssued) {
  return;
}
boolean serverConcurrencyChecksEnabled = this.concurrencyChecksEnabled;
boolean clientConcurrencyChecksEnabled = tag != null;
if (clientConcurrencyChecksEnabled != serverConcurrencyChecksEnabled) {
  this.concurrencyMessageIssued = true;
  logger.info(LocalizedMessage.create(
  
LocalizedStrings.LocalRegion_SERVER_HAS_CONCURRENCY_CHECKS_ENABLED_0_BUT_CLIENT_HAS_1_FOR_REGION_2,
  new Object[] {serverConcurrencyChecksEnabled, 
clientConcurrencyChecksEnabled, this}));
}
  }
{code}

> Server has concurrencyChecksEnabled log message has the booleans switched
> -
>
> Key: GEODE-2792
> URL: https://issues.apache.org/jira/browse/GEODE-2792
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Priority: Trivial
>
> The log message: "Server has concurrencyChecksEnabled {0} but client has {1}" 
> should instead be:  "Server has concurrencyChecksEnabled {1} but client has 
> {0}".



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2792) Server has concurrencyChecksEnabled log message has the booleans switched

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2792:
---

 Summary: Server has concurrencyChecksEnabled log message has the 
booleans switched
 Key: GEODE-2792
 URL: https://issues.apache.org/jira/browse/GEODE-2792
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Darrel Schneider


The log message: "Server has concurrencyChecksEnabled {0} but client has {1}" 
should instead be:  "Server has concurrencyChecksEnabled {1} but client has 
{0}".




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2097) Offheap persistent heapLRU regions can run out of offheap memory during recovery

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2097.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Offheap persistent heapLRU regions can run out of offheap memory during 
> recovery
> 
>
> Key: GEODE-2097
> URL: https://issues.apache.org/jira/browse/GEODE-2097
> Project: Geode
>  Issue Type: Bug
>  Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When the data for a persistent region is being recovered from the disk store 
> the lru limit is constantly checked. If the lru limit is exceeded then value 
> recovery will cease. But for off-heap regions this lru limit should be 
> checking how much off-heap memory has been allocated.
> During recovery the amount of heap memory is being checked for an offheap 
> regions. So we can end up recovering too many values to off-heap and running 
> out of off-heap memory during recovery.
> The code that causes this problem is: 
> org.apache.geode.internal.cache.lru.HeapLRUCapacityController.createLRUHelper().new
>  AbstractEnableLRU() {...}.mustEvict(LRUStatistics, Region, int)
> During off-heap disk store recovery the Region parameter passed to this 
> method is "null". This causes the following heap check to be done:
>if (region == null) {
>   return resourceManager.getHeapMonitor().getState().isEviction();
> }



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2485.
-
Resolution: Fixed

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reopened GEODE-2485:
-

The previous fix broke this unit test: PartitionedRegionQueryEvaluatorTest
So that fix has been reverted and a new one will be checked in.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2485.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15957925#comment-15957925
 ] 

Darrel Schneider commented on GEODE-2485:
-

It looks like a simple way to optimize code that suspends and resumes in a 
try/finally it to call internalSuspend instead of suspend. Since the finally 
block will always call resume we can safely use internalSuspend which does not 
schedule expiration with the SystemTimer.

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2485:
---

Assignee: Darrel Schneider

> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2727:
---

 Summary: optimize new 1.8 ConcurrentMap default methods on Region
 Key: GEODE-2727
 URL: https://issues.apache.org/jira/browse/GEODE-2727
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


In JDK 1.8 ConcurrentMap added the following default methods to the interface:
  getOrDefault
  computeIfAbsent
  computeIfPresent
  compute
  merge
  foreach
  replaceAll

All of the default implementations of these methods have issues with get 
returning null when the key actually exists. So they do not support invalid 
region entries.
The other problem with all of them (except getOrDefault) is that they will make 
multiple round trips when done from a proxy. In a distributed environment we 
should implement these to send the lambda to the primary so that the entire 
operation can be done with one message and while the RegionEntry is locked.
This would require that the lambda parameter by serializable which would be 
consistent with what we do for other parameters to Region methods (for example 
"put").
>From a performance point of view "foreach" and "replaceAll" are the worst 
>since they bring back to whoever is executing the method all the keys and 
>values from the entire cluster.
It is also worth considering how the operations behave in a geode transaction.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2722) ReflectionBasedAutoSerializer should be used by default

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944333#comment-15944333
 ] 

Darrel Schneider commented on GEODE-2722:
-

The PdxSerializer is used before java serialization. So if you have a class 
that implements java serialization (by implementing Serializable or 
Externalizable or one of the other ways ObjectOutputStream supports) it would 
no longer be java serialized but would instead be serialized as a PDX. So 
making this change could break existing applications that rely on java 
serialization.
To get the old behaviour you should be able to configure the pdx-serializer to 
be null.


> ReflectionBasedAutoSerializer should be used by default
> ---
>
> Key: GEODE-2722
> URL: https://issues.apache.org/jira/browse/GEODE-2722
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Swapnil Bawaskar
>
> We should not require the user to configure anything when inserting data in 
> Geode. ReflectionBasedAutoSerializer should be set by default on Cache
> startup (if one is not specified already). 
> Also, the pattern required to configure ReflectionBasedAutoSerializer should 
> be made optional: Please see:
> 
> Please look at this thread for discussion on the dev list: 
> https://lists.apache.org/thread.html/c89974d08d7675d3a636872bce5e838d578df5759c5c1acae611d322@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2722) ReflectionBasedAutoSerializer should be used by default

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15944321#comment-15944321
 ] 

Darrel Schneider commented on GEODE-2722:
-

So the default pattern would match all class names?

> ReflectionBasedAutoSerializer should be used by default
> ---
>
> Key: GEODE-2722
> URL: https://issues.apache.org/jira/browse/GEODE-2722
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Swapnil Bawaskar
>
> We should not require the user to configure anything when inserting data in 
> Geode. ReflectionBasedAutoSerializer should be set by default on Cache
> startup (if one is not specified already). 
> Also, the pattern required to configure ReflectionBasedAutoSerializer should 
> be made optional: Please see:
> 
> Please look at this thread for discussion on the dev list: 
> https://lists.apache.org/thread.html/c89974d08d7675d3a636872bce5e838d578df5759c5c1acae611d322@%3Cdev.geode.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2723) remove "localCacheEnabled" dead code from PartitionedRegion

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2723:
---

 Summary: remove "localCacheEnabled" dead code from 
PartitionedRegion
 Key: GEODE-2723
 URL: https://issues.apache.org/jira/browse/GEODE-2723
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


The PartionedRegion class has a final field named "localCacheEnabled". It is 
always false and never set to true. We have 5 methods that test for it being 
true and do a bunch of stuff. This dead code should be removed.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2472) Oplog.flush method doesn't verify that the entry gets written

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2472.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> Oplog.flush method doesn't verify that the entry gets written
> -
>
> Key: GEODE-2472
> URL: https://issues.apache.org/jira/browse/GEODE-2472
> Project: Geode
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Kenneth Howe
>Assignee: Anilkumar Gingade
> Fix For: 1.2.0
>
>
> The Oplog.flush(OplogFile olf, ByteBuffer b1, ByteBuffer b2) method doesn't 
> check the results of the channel.write() call. The other Oplog.flush() method 
> that performs a channel write wraps the write() call in the loop
> {code}
> do {
> ...
> } while (hasRemaining);
> {code}
> to make sure the Oplog entry is written to the OplogFile.
> This method is implemented without the check loop, making the assumption that 
> the write() completely writes everything from both buffers. Defensive 
> programming would suggest that the results of lower level calls are checked.
> Failure to recognize a partial write to the OplogFile can result in a corrupt 
> oplog that isn't found until the persistent disk store is recovered.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2719) The total-max-memory region attribute does not appear to do anything

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2719:
---

 Summary: The total-max-memory region attribute does not appear to 
do anything
 Key: GEODE-2719
 URL: https://issues.apache.org/jira/browse/GEODE-2719
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Darrel Schneider


I could not find that the "total-max-memory" region partitioned attribute does 
anything. If this is correct then it should be deprecated and removed in a 
future release. A user read the geode docs and expected it cause LRU eviction 
since this docs say this about it:
{quote}
Maximum combined megabytes of memory to be used by all processes hosting this 
region for all copies, primary and redundant.
{quote}




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2680) Gfsh start server command hangs while waiting for offline members

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2680:

Component/s: (was: persistence)

> Gfsh start server command hangs while waiting for offline members
> -
>
> Key: GEODE-2680
> URL: https://issues.apache.org/jira/browse/GEODE-2680
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Jason Huynh
> Attachments: cache.xml, oplogs1.tar.gz
>
>
> When starting up a server with persistent files, the server waits for the 
> other offline members as expected.  However the gfsh command seems to not 
> abort and instead is “stuck.”  Gfsh should complete and allow the user/admin 
> to continue administering commands to revoke members etc.
> Attached is a cache xml file and oplogs to reproduce the file.
> Steps to reproduce:
> Configuration:
> 1.) Edit the cache.xml file to point to the appropriate disk store location
> Commands:
> 1.) start locator —-name=locator1
> 2.) start server --name=server1  -—cache-xml-file=cache.xml
> Now the process is stuck.  In my run the locator eventually shuts itself down 
> too...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-1235) Geode should handle client reconnect scenario and not simply remove disconnected client transaction after 180 seconds

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-1235:

Summary: Geode should handle client reconnect scenario and not simply 
remove disconnected client transaction after 180 seconds  (was: Geode should 
handle client reconnect scenario and not simply remove disconeected client 
transaction after 180 seconds)

> Geode should handle client reconnect scenario and not simply remove 
> disconnected client transaction after 180 seconds
> -
>
> Key: GEODE-1235
> URL: https://issues.apache.org/jira/browse/GEODE-1235
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>
> Currently in GEODE, once a client is disconnected from server, all its client 
> transactions are scheduled to be removed in 180 second. It is possible that 
> the client reconnects to another server, and the transactions could continue. 
> If a transaction is not finished (committed or rolled back) in 180 seconds, 
> the scheduled transaction removal will kick in and cause the existing 
> transactional operations to be lost and client won't know about this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-1235) Geode should handle client reconnect scenario and not simply remove disconeected client transaction after 180 seconds

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-1235:

Description: 
Currently in GEODE, once a client is disconnected from server, all its client 
transactions are scheduled to be removed in 180 second. It is possible that the 
client reconnects to another server, and the transactions could continue. If a 
transaction is not finished (committed or rolled back) in 180 seconds, the 
scheduled transaction removal will kick in and cause the existing transactional 
operations to be lost and client won't know about this.


  was:
{noformat}
Currently in GEODE, once a client is disconnected from server, all its client 
transactions are scheduled to be removed in 180 second. It is possible that the 
client reconnects to another server, and the transactions could continue. If a 
transaction is not finished (committed or rolled back) in 180 seconds, the 
scheduled transaction removal will kick in and cause the existing transactional 
operations to be lost and client won't know about this.

{noformat}


> Geode should handle client reconnect scenario and not simply remove 
> disconeected client transaction after 180 seconds
> -
>
> Key: GEODE-1235
> URL: https://issues.apache.org/jira/browse/GEODE-1235
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>
> Currently in GEODE, once a client is disconnected from server, all its client 
> transactions are scheduled to be removed in 180 second. It is possible that 
> the client reconnects to another server, and the transactions could continue. 
> If a transaction is not finished (committed or rolled back) in 180 seconds, 
> the scheduled transaction removal will kick in and cause the existing 
> transactional operations to be lost and client won't know about this.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-1969) oplog closed while writing to oplog with gemfire.syncWrites=true

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-1969.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> oplog closed while writing to oplog with gemfire.syncWrites=true
> 
>
> Key: GEODE-1969
> URL: https://issues.apache.org/jira/browse/GEODE-1969
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> [info 2016/09/29 06:16:06.823 UTC  oplog#6> tid=0x19] OplogCompactor for nsxDiskStore compaction oplog id(s): 
> oplog#6
> [info 2016/09/29 06:16:08.232 UTC  oplog#6> tid=0x19] compaction did 6,310 creates and updates in 1,408 ms
> [info 2016/09/29 06:16:08.248 UTC  tid=0x19] Deleted 
> oplog#6 crf for disk store nsxDiskStore.
> [info 2016/09/29 06:16:08.256 UTC  tid=0x19] Deleted 
> oplog#6 krf for disk store nsxDiskStore.
> [info 2016/09/29 06:16:08.256 UTC  tid=0x19] Deleted 
> oplog#6 drf for disk store nsxDiskStore.
> [info 2016/09/29 06:17:03.887 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] Created oplog#8 drf 
> for disk store nsxDiskStore.
> [info 2016/09/29 06:17:03.911 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] Created oplog#8 crf 
> for disk store nsxDiskStore.
> [info 2016/09/29 06:17:04.031 UTC  tid=0x19] Created 
> oplog#7 krf for disk store nsxDiskStore.
> [info 2016/09/29 06:17:04.314 UTC  oplog#7> tid=0x19] OplogCompactor for nsxDiskStore compaction oplog id(s): 
> oplog#7
> [error 2016/09/29 06:17:16.075 UTC  oplog#7> tid=0x19] A DiskAccessException has occurred while writing to the 
> disk for disk store nsxDiskStore. The cache will be closed. 
> ?com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by java.io.IOException: Stream Closed ?at 
> com.gemstone.gemfire.internal.cache.Oplog.flushAll(Oplog.java:5235)
> [warn 2016/09/29 06:17:16.297 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher@55bded67:
>  Exception during processing batch 448
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderException: 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher@55bded67:
>  Exception during processing batch 448, caused by 
> com.gemstone.gemfire.cache.CacheClosedException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused by 
> java.io.IOException: Stream Closed
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:173)
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:83)
> at 
> com.gemstone.gemfire.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:579)
> at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:219)
> Caused by: com.gemstone.gemfire.cache.CacheClosedException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused by 
> com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by java.io.IOException: Stream Closed
> at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1299)
> at 
> com.gemstone.gemfire.CancelCriterion.checkCancelInProgress(CancelCriterion.java:82)
> at 
> com.gemstone.gemfire.internal.cache.TXManagerImpl.checkClosed(TXManagerImpl.java:606)
> at 
> com.gemstone.gemfire.internal.cache.TXManagerImpl.begin(TXManagerImpl.java:279)
> at 
> com.vmware.nsx.management.container.dao.gemfire.GemFireTxLogDao.processTxLog(GemFireTxLogDao.java:119)
> at 
> com.vmware.nsx.management.container.dao.gemfire.TxLogAsyncEventListener.processEvents(TxLogAsyncEventListener.java:93)
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:164)
> ... 3 more
> Caused by: com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> 

[jira] [Resolved] (GEODE-654) Interaction of GII and LIFO eviction can cause high CPU and recovery issues

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-654.

   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

The fix is on geode in git rev: f7670e1688a95a026a0376724bfe2277cb16eb94

> Interaction of GII and LIFO eviction can cause high CPU and recovery issues
> ---
>
> Key: GEODE-654
> URL: https://issues.apache.org/jira/browse/GEODE-654
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: Vincent Ford
>Assignee: Vincent Ford
> Fix For: 1.0.0-incubating
>
>
> This was seen in a customer engagement with GemFire but also effects Geode 
> and the usage of  LIFO eviction algorithm.  The GemFire support team led by 
> David Wisler identified the following pattern. In the specific case the GII 
> was blocked from completing processing and also blocked a put into the 
> processing queue of a Gateway ( not part of Geode but would effect any usage 
> of LIFO eviction ).
> (** 1 **)
> "Pooled High Priority Message Processor 4" daemon prio=10 
> tid=0x2ba27c008800 nid=0x3fc5 waiting for monitor entry 
> [0x2ba1894f2000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> com.gemstone.gemfire.internal.cache.InitialImageOperation$RequestImageMessage.chunkEntries(InitialImageOperation.java:1555)
>   - waiting to lock <0x0005b81413d0> (a 
> com.gemstone.gemfire.internal.cache.VersionedStatsRegionEntry)
> 1554  synchronized(mapEntry) { // bug #46042 must sync to make sure the tag 
> goes with the value
> 1555  VersionSource id = stamp.getMemberID();
> 1556  if (id == null) { id = myId; }
> 1557  foundIds.add(id);
> 1558  // if the recipient passed a version vector, use it to 
> filter out
> 1559  // entries the recipient already has
> (** 2 **)
> "pool-26-thread-4" prio=10 tid=0x2ba390042800 nid=0x4073 waiting for 
> monitor entry [0x2ba18b4d]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderQueue.put(SerialGatewaySenderQueue.java:205)
>   - waiting to lock <0x0005b7624058> (a 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderQueue)
>   at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.queuePrimaryEvent(SerialGatewaySenderEventProcessor.java:440)
>   at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.enqueueEvent(SerialGatewaySenderEventProcessor.java:416)
>   at 
> com.gemstone.gemfire.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:964)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.notifyGatewayHubs(LocalRegion.java:6295)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5858)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:3203)
>   - locked <0x0005b81413d0> (a 
> com.gemstone.gemfire.internal.cache.VersionedStatsRegionEntry)
> Below it is clear that we are not getting out of the eviction loop, for some 
> reason the method "evictEntry" is returning 0 as the amount of evicted bytes 
> and that's why following  thread keeps swapping between BLOCKED and RUNNABLE 
> and making no progress.
> [2015-09-08 12:39:09]
> "pool-26-thread-2" prio=10 tid=0x2ba390005000 nid=0x406f waiting for 
> monitor entry [0x2ba18b34b000]
>java.lang.Thread.State: BLOCKED (on object monitor)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractLRURegionMap.evictEntry(AbstractLRURegionMap.java:302)
>   - locked <0x0005b9b7c8c8> (a 
> com.gemstone.gemfire.internal.cache.VersionedThinDiskLRURegionEntry)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractLRURegionMap.lruUpdateCallback(AbstractLRURegionMap.java:522)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:3272)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractLRURegionMap.basicPut(AbstractLRURegionMap.java:45)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5669)
>   at 
> com.gemstone.gemfire.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:375)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:118)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.basicPut(LocalRegion.java:5050)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1747)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.put(LocalRegion.java:1729)
>   at 
> 

[jira] [Assigned] (GEODE-1969) oplog closed while writing to oplog with gemfire.syncWrites=true

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-1969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-1969:
---

Assignee: Darrel Schneider  (was: Amey Barve)

> oplog closed while writing to oplog with gemfire.syncWrites=true
> 
>
> Key: GEODE-1969
> URL: https://issues.apache.org/jira/browse/GEODE-1969
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> [info 2016/09/29 06:16:06.823 UTC  oplog#6> tid=0x19] OplogCompactor for nsxDiskStore compaction oplog id(s): 
> oplog#6
> [info 2016/09/29 06:16:08.232 UTC  oplog#6> tid=0x19] compaction did 6,310 creates and updates in 1,408 ms
> [info 2016/09/29 06:16:08.248 UTC  tid=0x19] Deleted 
> oplog#6 crf for disk store nsxDiskStore.
> [info 2016/09/29 06:16:08.256 UTC  tid=0x19] Deleted 
> oplog#6 krf for disk store nsxDiskStore.
> [info 2016/09/29 06:16:08.256 UTC  tid=0x19] Deleted 
> oplog#6 drf for disk store nsxDiskStore.
> [info 2016/09/29 06:17:03.887 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] Created oplog#8 drf 
> for disk store nsxDiskStore.
> [info 2016/09/29 06:17:03.911 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] Created oplog#8 crf 
> for disk store nsxDiskStore.
> [info 2016/09/29 06:17:04.031 UTC  tid=0x19] Created 
> oplog#7 krf for disk store nsxDiskStore.
> [info 2016/09/29 06:17:04.314 UTC  oplog#7> tid=0x19] OplogCompactor for nsxDiskStore compaction oplog id(s): 
> oplog#7
> [error 2016/09/29 06:17:16.075 UTC  oplog#7> tid=0x19] A DiskAccessException has occurred while writing to the 
> disk for disk store nsxDiskStore. The cache will be closed. 
> ?com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by java.io.IOException: Stream Closed ?at 
> com.gemstone.gemfire.internal.cache.Oplog.flushAll(Oplog.java:5235)
> [warn 2016/09/29 06:17:16.297 UTC  GatewaySender_AsyncEventQueue_txLogEventQueue> tid=0x19] 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher@55bded67:
>  Exception during processing batch 448
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderException: 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher@55bded67:
>  Exception during processing batch 448, caused by 
> com.gemstone.gemfire.cache.CacheClosedException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused by 
> java.io.IOException: Stream Closed
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:173)
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:83)
> at 
> com.gemstone.gemfire.internal.cache.wan.AbstractGatewaySenderEventProcessor.processQueue(AbstractGatewaySenderEventProcessor.java:579)
> at 
> com.gemstone.gemfire.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.run(SerialGatewaySenderEventProcessor.java:219)
> Caused by: com.gemstone.gemfire.cache.CacheClosedException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused by 
> com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: nsxDiskStore: 
> Failed writing key to "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused 
> by java.io.IOException: Stream Closed
> at 
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:1299)
> at 
> com.gemstone.gemfire.CancelCriterion.checkCancelInProgress(CancelCriterion.java:82)
> at 
> com.gemstone.gemfire.internal.cache.TXManagerImpl.checkClosed(TXManagerImpl.java:606)
> at 
> com.gemstone.gemfire.internal.cache.TXManagerImpl.begin(TXManagerImpl.java:279)
> at 
> com.vmware.nsx.management.container.dao.gemfire.GemFireTxLogDao.processTxLog(GemFireTxLogDao.java:119)
> at 
> com.vmware.nsx.management.container.dao.gemfire.TxLogAsyncEventListener.processEvents(TxLogAsyncEventListener.java:93)
> at 
> com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventCallbackDispatcher.dispatchBatch(GatewaySenderEventCallbackDispatcher.java:164)
> ... 3 more
> Caused by: com.gemstone.gemfire.cache.DiskAccessException: For DiskStore: 
> nsxDiskStore: Failed writing key to 
> "/common/nsxapi/data/self/BACKUPnsxDiskStore_7", caused by 
> 

[jira] [Resolved] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2616.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2616:

Affects Version/s: 1.1.0

> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2616:
---

Assignee: Darrel Schneider

> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2616:
---

 Summary: A colocated paritioned region will leak memory when it is 
closed or destroyed
 Key: GEODE-2616
 URL: https://issues.apache.org/jira/browse/GEODE-2616
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Darrel Schneider


When a colocated partitioned region is created it registers itself with the 
parent region it is colocated with. When that same region is closed or 
destroyed it does not deregister itself from the parent.
This results in a memory leak that remains until the parent region is itself 
closed or destroyed.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Reopened] (GEODE-2428) Add support for LinkedHashMap in DataSerializer

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reopened GEODE-2428:
-

I think the javadocs on these new methods need to make two more things clear:
  1. readLinkedHashMap will always create a LinkedHashMap that uses insertion 
order. Even if the one serialized by writeLinkedHashMap was access order.
  2. writeLinkedHashMap is not used by DataSerializer.writeObject to serialize 
a LinkedHashMap. The other static methods on DataSerializer (for example 
writeHashMap) are used by DataSerializer.writeObject so I think this "exception 
to the rule" should be called out in javadocs.

It would be nice if writeObject did call writeLinkedHashMap but that would 
introduce backward compatibility issues. The reason this was not done at the 
time LinkedHashSet support was added was because of the "access" vs. 
"insertion" order issue #1.


> Add support for LinkedHashMap in DataSerializer
> ---
>
> Key: GEODE-2428
> URL: https://issues.apache.org/jira/browse/GEODE-2428
> Project: Geode
>  Issue Type: Improvement
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
> Fix For: 1.2.0
>
>
> DataSerializer should also support serialization and de-serialization of 
> DataSerializer



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2535) DiskId keyId is not correctly updated

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15881659#comment-15881659
 ] 

Darrel Schneider commented on GEODE-2535:
-

Another related bug is code in the same basicUpdate method that uses 
"did.getKeyId()" to determine the current state of the region entry (i.e. if 
the value is inVM or onDisk).
I think the code would be much clearer if we quit negating the recoveredKeyId 
on RecoveredEntry and instead just added a boolean flag to it that lets us say 
we have a value or it is still on disk.
The keyId itself on DiskId should not be mutated; it should be final. The only 
place in the code that calls DiskId.isKeyIdNegative simply makes it positive so 
I think if we just leave it positive all the time the code will be easier to 
understand. basicUpdate will need to be changed to no longer use 
"did.getKeyId()" to determine the current state. But this can be done in the 
same way updateRecoveredEntry does it.

> DiskId keyId is not correctly updated
> -
>
> Key: GEODE-2535
> URL: https://issues.apache.org/jira/browse/GEODE-2535
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Darrel Schneider
>
> On a persistent region the DiskId keyId will be set negative if the value is 
> not in memory but can be read from disk.
> The code correctly sets it the first time an entry is recovered from disk but 
> does not correctly update it if a that same entry is recovered more than once 
> from disk. This can happen when a krf for an oplog does not exist. The same 
> entry can have multiple records for the same key.
> They code that does not correctly update DiskId keyId is in these methods:
> org.apache.geode.internal.cache.DiskEntry.Helper.basicUpdate(DiskEntry, 
> LocalRegion, Object, EntryEventImpl): see the section that handles 
> RecoveredEntry
> and 
> org.apache.geode.internal.cache.DiskEntry.Helper.updateRecoveredEntry(PlaceHolderDiskRegion,
>  DiskEntry, RecoveredEntry, RegionEntryContext)
> The only issue with not updating this keyId is that it can cause the "inVM" 
> and "onDisk" statistics to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2536) DiskId code confusing in how it implements needsToBeWritten

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2536:
---

 Summary: DiskId code confusing in how it implements 
needsToBeWritten
 Key: GEODE-2536
 URL: https://issues.apache.org/jira/browse/GEODE-2536
 Project: Geode
  Issue Type: Improvement
  Components: persistence
Reporter: Darrel Schneider


DiskId has an abstract method "needsToBeWritten." It is set to true by 
"markForWriting" and set to false by "unmarkForWriting." DiskId has two types 
of implementations: one for overflow only regions and one for persistent 
regions.
The needsToBeWritten only makes sense for overflow only. But the persistent 
DiskIds also implement these methods and do so in a way that can be confused 
with "isKeyIdNegative."

Since markForWriting will only be called for overflow only disk ids I recommend 
that the persistent implementation of this method be changed to always throw an 
exception.

unmarkForWriting may be called on any type of disk id but for persistent ones 
should be changed to do nothing.

needsToBeWritten should be changed to always return false for persistent 
DiskIds since they are immediately written to disk (or scheduled to be written 
if async) by whoever gives them a new value. needsToBeWritten is only called by 
the overflowToDisk method and for a persistent+overflow region it should never 
need to write the value to disk; all it needs to do is remove the value from 
memory since it is written to disk.

The current implementation of these methods on persistent DiskIds do it by 
negating the keyId. Unfortunately this is also done to indicate that the value 
was not recovered from disk.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2535) DiskId keyId is not correctly updated

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2535:
---

 Summary: DiskId keyId is not correctly updated
 Key: GEODE-2535
 URL: https://issues.apache.org/jira/browse/GEODE-2535
 Project: Geode
  Issue Type: Bug
  Components: persistence
Reporter: Darrel Schneider


On a persistent region the DiskId keyId will be set negative if the value is 
not in memory but can be read from disk.
The code correctly sets it the first time an entry is recovered from disk but 
does not correctly update it if a that same entry is recovered more than once 
from disk. This can happen when a krf for an oplog does not exist. The same 
entry can have multiple records for the same key.

They code that does not correctly update DiskId keyId is in these methods:
org.apache.geode.internal.cache.DiskEntry.Helper.basicUpdate(DiskEntry, 
LocalRegion, Object, EntryEventImpl): see the section that handles 
RecoveredEntry
and 
org.apache.geode.internal.cache.DiskEntry.Helper.updateRecoveredEntry(PlaceHolderDiskRegion,
 DiskEntry, RecoveredEntry, RegionEntryContext)

The only issue with not updating this keyId is that it can cause the "inVM" and 
"onDisk" statistics to be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15876399#comment-15876399
 ] 

Darrel Schneider commented on GEODE-2485:
-

In addition to fixing the code to periodically purge the SystemTimer, it would 
also be worth changing fetchRemoteVersionTag to not use suspend/resume. All 
that this code is doing is sending a message. The code wants this message to 
always be done outside of a transaction so it suspends. But a more performant 
way of doing this is just to refactor the code on the RemoteOperationMessage 
that initializes the txUniqId, txMemberId, and isTransactionDistributed 
instance variables into a protected method called initializeTransaction. Then 
override this method in RemoteFetchVersionMessage to do nothing.


> CacheTransactionManager suspend/resume can leak memory for 30 minutes
> -
>
> Key: GEODE-2485
> URL: https://issues.apache.org/jira/browse/GEODE-2485
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Darrel Schneider
>
> Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
> allocated for 30 minutes. If you are doing a high rate of suspend/resume 
> calls then this could cause you to run out of memory in that 30 minute window.
> As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small 
> as 1 (which would cause the memory to be freed up after 1 minute instead of 
> 30 minutes).
> One fix for this is to periodically call cache.getCCPTimer().timerPurge() 
> after a certain number of resume calls have been done (for example 1000). 
> Currently resume is calling cancel on the TimerTask but that leaves the task 
> in the SystemTimer queue until it expires. Calling timerPurge it addition to 
> cancel will fix this bug. Calling timerPurge for every cancel may cause the 
> resume method to take too long and keep in mind the getCCPTimer is used by 
> other things so the size of the SystemTimer queue that is being purged will 
> not only be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (GEODE-2485) CacheTransactionManager suspend/resume can leak memory for 30 minutes

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2485:
---

 Summary: CacheTransactionManager suspend/resume can leak memory 
for 30 minutes
 Key: GEODE-2485
 URL: https://issues.apache.org/jira/browse/GEODE-2485
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Darrel Schneider


Each time you suspend/resume a transaction it leaves about 80 bytes of heap 
allocated for 30 minutes. If you are doing a high rate of suspend/resume calls 
then this could cause you to run out of memory in that 30 minute window.

As a workaround you can set -Dgemfire.suspendedTxTimeout to a value as small as 
1 (which would cause the memory to be freed up after 1 minute instead of 30 
minutes).

One fix for this is to periodically call cache.getCCPTimer().timerPurge() after 
a certain number of resume calls have been done (for example 1000). Currently 
resume is calling cancel on the TimerTask but that leaves the task in the 
SystemTimer queue until it expires. Calling timerPurge it addition to cancel 
will fix this bug. Calling timerPurge for every cancel may cause the resume 
method to take too long and keep in mind the getCCPTimer is used by other 
things so the size of the SystemTimer queue that is being purged will not only 
be the number of suspended txs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864748#comment-15864748
 ] 

Darrel Schneider commented on GEODE-697:


Anil and I both think the solution to this is that when a client gives up on an 
operation that it times out and is not going to retry that operation, then it 
must change its thread id that is used by the server EventTracker. I think the 
client adds this to every message it sends by getting it from a thread id. So 
it should be pretty easy for it to modify it in the exceptional case of it 
giving up on an in progress operation. This was the solution that Dan suggested 
in the original comment.

I think we only need the EventTracker because clients may retry to same 
operation and we want to not do duplicates on the server side when a client has 
done a retry. So the client only needs to maintain the same EventTracker id if 
it may still retry an operation that may still be in progress.

> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>Assignee: Darrel Schneider
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-697:
--

Assignee: (was: Darrel Schneider)

> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (GEODE-697) A client thread timing out an operation and performing further operations can result in cache inconsistency

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-697:
---
Component/s: (was: regions)
 client/server

> A client thread timing out an operation and performing further operations can 
> result in cache inconsistency
> ---
>
> Key: GEODE-697
> URL: https://issues.apache.org/jira/browse/GEODE-697
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Dan Smith
>Assignee: Darrel Schneider
>
> There is a case where the primary and secondary buckets of a partitioned 
> region can become out of sync if a client times out while waiting for a slow 
> operation to finish. Here's the scenario:
> 1. A operation is started by the client and gets stuck on the server, for 
> example by a slow cache writer. That operation is assigned an EventID  with a 
> sequence number of 1.
> 2. The client times out.
> 3. The client performs a second operation. That operation gets assigned an 
> EventID with a sequence number of 2.
> 4. The second operation is applied on all members. The EventTracker records 
> the sequence number 2.
> 5. The original operation continues. It is applied to the primary (because it 
> has passed the EventTracker test).
> 6. The original operation is rejected by the EventTracker on the secondary. 
> The two copies of the bucket are now inconsistent.
> One possible fix is to change the thread id of the thread on the client when 
> the client operation times out. That would ensure that the EventTracker will 
> not reject the original operation when it finally goes through, because it 
> has a different thread id.
> If an operation is delayed on the server, for example by a very slow cache 
> writer, the operation can time out on the client.
> The client can then go on and perform a second operation.
> The problem is that each operation is assigned an event id which is a 
> combination of the clients thread id and a sequence number. That second 
> operation has a higher sequence number.
> Once the second operation is applied to a region on a given member, the event 
> is stored in the EventTracker and that member will reject any lower sequence 
> numbers



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2453) region.create does not honor contract on PROXY region

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864644#comment-15864644
 ] 

Darrel Schneider commented on GEODE-2453:
-

This is actually the expected behavior with how PROXY regions are currently 
specified to behave.
Create is checking if the local PROXY region has an existing entry. Since the 
PROXY is always empty it does not and the create operation is allowed and 
distributed to others.
In the new specification of PROXY regions in which they will always forward the 
operation to be done on the server (see GEODE-1887) create should be changed to 
check the server for an existing key instead of checking the state on the local 
PROXY.

> region.create does not honor contract on PROXY region
> -
>
> Key: GEODE-2453
> URL: https://issues.apache.org/jira/browse/GEODE-2453
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>
> A create(K,V) on a client PROXY region does not throw an 
> {{EntryExistsException}} when the entry already exists on the server.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2375) GemFireException should not inherit from RuntimeException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864127#comment-15864127
 ] 

Darrel Schneider commented on GEODE-2375:
-

Something that might work, and not break old code, is to introduce a new 
abstract subclass of GemFireException called GeodeRuntimeException. We would 
deprecate GemFireException saying to instead use GeodeRuntimeException. Any of 
our current instances of GemFireException would be changed to instead subclass 
GeodeRuntimeException. Old code that catches GemFireException or does 
instanceof checks would continue to work. We would need to confirm that if we 
java serialize an instance of one of the exception that used to subclass 
GemFireException but now subclass GeodeRuntimeException would still deserialize 
in an old client that does not have GeodeRuntimeException on its classpath.

We would do all of the above with GemFireCheckedException except its new 
abstract subclass would be GeodeException.


> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
>  Issue Type: Bug
>  Components: core, general
>Reporter: Galen O'Sullivan
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the 
> majority of exceptions in Geode are unchecked. This means that we don't have 
> the type system helping us to check potential failure conditions of our code, 
> and it's not clear which functions may throw exceptions as a part of their 
> nomal failure modes -- for example, {{ReplyException}} has a 
> {{handleAsUnexpected}} method that seems to indicate that a normal 
> {{ReplyException}} is not unexpected -- but that's not what the type 
> inheritance says. {{GemFireException}} accounts for most of the exceptions in 
> the codebase.
> Even if we were to convert most of the existing instances of 
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially 
> new ones) would still be tempted to use {{GemFireException}} for new 
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit 
> from a central exception type, which I'm not entirely sold on) would be to 
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and 
> deprecate both kinds of {{GemFireException}}? Then we could convert old 
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to 
> change it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2471) AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15864106#comment-15864106
 ] 

Darrel Schneider commented on GEODE-2471:
-

It looks like this failure is caused by the AsyncEventListener the test sets up 
not having its processEvent method called (which would have caused it to set 
moved to true).
I see line 1675 as this: assertTrue(getBucketMoved(vm2, "ln"));
and getBucketMoved just tests the moved flag on the test's AsyncEventListener 
impl.

> AsyncEventListenerOffHeapDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching
> --
>
> Key: GEODE-2471
> URL: https://issues.apache.org/jira/browse/GEODE-2471
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: xiaojian zhou
>  Labels: CI
>
> {noformat}
> found in concourse distributedTest #383
> 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.internal.cache.wan.asyncqueue.AsyncEventListenerDUnitTest.testParallelAsyncEventQueueMoveBucketAndMoveItBackDuringDispatching(AsyncEventListenerDUnitTest.java:1675)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> 

[jira] [Commented] (GEODE-2436) Geode doesn't handle byte[] as key

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862126#comment-15862126
 ] 

Darrel Schneider commented on GEODE-2436:
-

Geode does not support any instance of a java array as a key. Java arrays have 
identity equals and hashCode which does not work as a Region key. We do 
document that a class can only be used as a Region key if it implements equals 
and hashCode.

> Geode doesn't handle byte[] as key
> --
>
> Key: GEODE-2436
> URL: https://issues.apache.org/jira/browse/GEODE-2436
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Hitesh Khamesra
>
> Geode doesn't handle byte[] as key. "byte[]" doesn't implement 
> hashcode/equals method, it just returns native hashcode. Because of that 
> following code returns  null for key k2;
> {code}
> Cache c = CacheFactory.getAnyInstance();
>
> Region region = c.getRegion("primitiveKVStore");
>byte[] k1 = new byte[] {1,2};
>
> region.put(k1, k1);
> byte[] k2 = new byte[] {1,2};
> System.out.println(">> "  + region.get(k2));
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2452) invalidateRegion on a CACHING_PROXY region throws NPE

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862120#comment-15862120
 ] 

Darrel Schneider commented on GEODE-2452:
-

I could not get the line numbers to match up to my code but I think the NPE is 
coming from this line:
  getMessage().addBytesPart(event.getEventId().calcBytes());

Code inspection shows that when the EntryEventImpl is created that the eventId 
is never set so the above line would result in an NPE.
This makes me think that client "invalidateRegion" has been broken for a long 
time.

I also wonder if its attempted implementation is correct. It attempts to only 
invalidate server region entries that exist on the client. I think it would be 
more correct for the client to just send a single message to the server telling 
it to invalidate the entire region. That is how the p2p invalidateRegion is 
implemented.


> invalidateRegion on a CACHING_PROXY region throws NPE
> -
>
> Key: GEODE-2452
> URL: https://issues.apache.org/jira/browse/GEODE-2452
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Swapnil Bawaskar
>
> Calling invalidateRegion on a CACHING_PROXY threw the following Exception:
> {noformat}
> Exception in thread "main" java.lang.NullPointerException
>   at 
> org.apache.geode.cache.client.internal.InvalidateOp$InvalidateOpImpl.(InvalidateOp.java:67)
>   at 
> org.apache.geode.cache.client.internal.InvalidateOp.execute(InvalidateOp.java:47)
>   at 
> org.apache.geode.cache.client.internal.ServerRegionProxy.invalidate(ServerRegionProxy.java:221)
>   at 
> org.apache.geode.internal.cache.LocalRegion.serverInvalidate(LocalRegion.java:3149)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.invalidate(AbstractRegionMap.java:2134)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.invalidateExistingEntry(LocalRegionDataView.java:67)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidate(LocalRegion.java:5223)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidate(LocalRegion.java:5187)
>   at 
> org.apache.geode.internal.cache.LocalRegion.invalidateAllEntries(LocalRegion.java:8045)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicInvalidateRegion(LocalRegion.java:7398)
>   at 
> org.apache.geode.internal.cache.LocalRegion.invalidateRegion(LocalRegion.java:1647)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.invalidateRegion(AbstractRegion.java:342)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (GEODE-2375) GemFireException should not inherit from RuntimeException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15862026#comment-15862026
 ] 

Darrel Schneider commented on GEODE-2375:
-

As the javadocs on GemFireException state it should have been named 
"GemFireRuntimeException". So I think it is wrong to say it should not inherit 
from RuntimeException. Instead you should say: "it should be named 
GemFireRuntimeException".

We also have a GemFireCheckedException (whose javadocs say it should have been 
named GemFireException).

It is not clear to me why you say: "which means that the majority of exceptions 
in Geode are unchecked". Any of our exception subclasses are free to extend 
either GemFireException or GemFireCheckedException. If they want to be a 
checked exception they are not forced to extend GemFireException. Exceptions 
are not added that often but when they are the author should consider if it 
should be a checked one or not and extend the correct class.

The reason these two exception classes did not have their name changed before 
was because of backwards compatibility. You would want to be careful not to 
break old code when trying to convert old exceptions to GeodeCheckedException 
and GeodeUncheckedException.

> GemFireException should not inherit from RuntimeException
> -
>
> Key: GEODE-2375
> URL: https://issues.apache.org/jira/browse/GEODE-2375
> Project: Geode
>  Issue Type: Bug
>  Components: core, general
>Reporter: Galen O'Sullivan
>
> {{GemFireException}} inherits from {{RuntimeException}}, which means that the 
> majority of exceptions in Geode are unchecked. This means that we don't have 
> the type system helping us to check potential failure conditions of our code, 
> and it's not clear which functions may throw exceptions as a part of their 
> nomal failure modes -- for example, {{ReplyException}} has a 
> {{handleAsUnexpected}} method that seems to indicate that a normal 
> {{ReplyException}} is not unexpected -- but that's not what the type 
> inheritance says. {{GemFireException}} accounts for most of the exceptions in 
> the codebase.
> Even if we were to convert most of the existing instances of 
> {{GemFireException}} to {{GemFireRuntimeException}}, developers (especially 
> new ones) would still be tempted to use {{GemFireException}} for new 
> exceptions.
> Perhaps the best way to solve this (if we want all our exceptions to inherit 
> from a central exception type, which I'm not entirely sold on) would be to 
> create a new {{GeodeUncheckedException}} and {{GeodeCheckedException}}, and 
> deprecate both kinds of {{GemFireException}}? Then we could convert old 
> exceptions as time permits.
> There's a significant amount of work involved here whatever way we decide to 
> change it.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2240.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

The previous fix caused a deadlock because of lock inversion.
This new fix prevents the lock inversion by added a new lock that is used to 
protect the expiredTombstones ArrayList.

> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.1.0
>
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2239) CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15773599#comment-15773599
 ] 

Darrel Schneider commented on GEODE-2239:
-

I think this test can be safely changed to not bind on a specific port. I 
commented out these two lines and the test still passes:
diff --git 
a/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java 
b/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
index 979da13..95d112c 100755
--- a/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
+++ b/geode-core/src/test/java/org/apache/geode/pdx/JSONFormatterJUnitTest.java
@@ -55,8 +55,8 @@ public class JSONFormatterJUnitTest {
 
 // start cache-server
 CacheServer server = c.addCacheServer();
-final int serverPort = 40405;
-server.setPort(serverPort);
+//final int serverPort = 40405;
+//server.setPort(serverPort);
 server.start();
 
 // Create region, primitiveKVStore


> CI failure: org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
> -
>
> Key: GEODE-2239
> URL: https://issues.apache.org/jira/browse/GEODE-2239
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Bruce Schuchardt
>  Labels: ci, flaky
>
> This test failed in Jenkins build #692.  It has a hard-coded port 40405 and 
> fails if the port isn't available.  
> https://builds.apache.org/job/Geode-nightly/692/testReport/
> {noformat}
>  org.apache.geode.pdx.JSONFormatterJUnitTest.testJSONFormatterAPIs
>  Error Details
> java.net.BindException: Failed to create server socket on  null[40,405]
>  Stack Trace
> java.net.BindException: Failed to create server socket on  null[40,405]
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:744)
>   at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:711)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:436)
>   at 
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:318)
>   at 
> org.apache.geode.pdx.JSONFormatterJUnitTest.setUp(JSONFormatterJUnitTest.java:59)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> 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.RunBefores.evaluate(RunBefores.java:24)
>   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.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> 

[jira] [Assigned] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider reassigned GEODE-2240:
---

Assignee: Darrel Schneider

> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.1.0
>
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider resolved GEODE-2240.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.1.0
>
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768328#comment-15768328
 ] 

Darrel Schneider commented on GEODE-2232:
-

In addition to the exceptions listed we also have the interface GemFireCache.
I'd also vote for not changing "gemfire" to "geode". I think it would be best 
to no longer have the product name in class names.


> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15768317#comment-15768317
 ] 

Darrel Schneider commented on GEODE-2232:
-

I think this would causes issues with being backwards compatible with version 
1.0.
I'm assigning this to Bruce because he recently worked on the compatibility 
issues caused by package renaming.


> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2232:

Assignee: Bruce Schuchardt

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2232) Rename GemFireConfigException

[Darrel Schneider (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GEODE-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Darrel Schneider updated GEODE-2232:

Component/s: (was: core)

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dor
> Fix For: 1.1.0
>
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

[ 
https://issues.apache.org/jira/browse/GEODE-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15767845#comment-15767845
 ] 

Darrel Schneider commented on GEODE-2240:
-

I think this bug might be caused by the code that adds to "expiredTombstones", 
TombstoneService.ReplicateTombstoneSweeper.expireTombstone, not syncing on 
getBlockGCLock() as the code that removes from "expiredTomstones", 
TombstoneService.ReplicateTombstoneSweeper.removeExpiredIf, does.
Since these are the only two methods that modify the "expiredTombstones" 
collection they need a common sync to prevent unsafe concurrent modification of 
the ArrayList.
I think the only time multiple threads would do this concurrently is when a 
region is being destroyed.


> unexpected NullPointerException from Tombstone service
> --
>
> Key: GEODE-2240
> URL: https://issues.apache.org/jira/browse/GEODE-2240
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>
> A test failed and the logs were found to be full of NPEs from the tombstone 
> service:[severe 2016/12/20 02:04:35.605 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
> at java.lang.Thread.run(Thread.java:745)
> [severe 2016/12/20 02:05:45.987 UTC 
> dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
>  tid=0x44] GemFire garbage 
> collection service encountered an unexpected exception
> java.lang.NullPointerException
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
> at 
> org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
> at 
> org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
> at java.lang.Thread.run(Thread.java:745)
> Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
> has nulls in it. It is an ArrayList of Tombstone instances and the only code 
> that adds to it first tests that the item it is adding is not null. The only 
> other modify operation done on it is to remove an item.
> Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2240) unexpected NullPointerException from Tombstone service

[Darrel Schneider (JIRA)]

Darrel Schneider created GEODE-2240:
---

 Summary: unexpected NullPointerException from Tombstone service
 Key: GEODE-2240
 URL: https://issues.apache.org/jira/browse/GEODE-2240
 Project: Geode
  Issue Type: Bug
  Components: regions
Reporter: Darrel Schneider


A test failed and the logs were found to be full of NPEs from the tombstone 
service:[severe 2016/12/20 02:04:35.605 UTC 
dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
 tid=0x44] GemFire garbage 
collection service encountered an unexpected exception
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.lambda$purgeObsoleteTombstones$1(TombstoneService.java:938)
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.removeExpiredIf(TombstoneService.java:479)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.removeIf(TombstoneService.java:823)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.purgeObsoleteTombstones(TombstoneService.java:937)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:880)
at java.lang.Thread.run(Thread.java:745)

[severe 2016/12/20 02:05:45.987 UTC 
dataStoregemfire7_rs-StorageBTTest-2016-12-19-23-35-42-client-14_19508 
 tid=0x44] GemFire garbage 
collection service encountered an unexpected exception
java.lang.NullPointerException
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.expireBatch(TombstoneService.java:524)
at 
org.apache.geode.internal.cache.TombstoneService$ReplicateTombstoneSweeper.checkExpiredTombstoneGC(TombstoneService.java:594)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.run(TombstoneService.java:878)
at java.lang.Thread.run(Thread.java:745)

Both of these stacks indicate that the "expiredTombstones" ArrayList somehow 
has nulls in it. It is an ArrayList of Tombstone instances and the only code 
that adds to it first tests that the item it is adding is not null. The only 
other modify operation done on it is to remove an item.
Perhaps unsafe concurrent access is happening causing this code to see nulls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)