[jira] [Updated] (GEODE-5164) refactor the three blocks of code in txApplyPut into one method
[ https://issues.apache.org/jira/browse/GEODE-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5164: -- Labels: pull-request-available (was: ) > refactor the three blocks of code in txApplyPut into one method > --- > > Key: GEODE-5164 > URL: https://issues.apache.org/jira/browse/GEODE-5164 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > > AbstractRegionMap.txApplyPut currently has three blocks of code that do the > put: > 1. applyTxUpdateOnReplicateOrRedundantCopy is called and much of the code in > it is the same as the oldRe block > 2. oldRe block: if an existing entry is found, do the put by changing it > 3. newRe block: if no existing entry is found, create a new entry and do the > put by changing it > It would help future refactoring of txApplyPut if these 3 blocks of code > could be consolidated into a single method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5167) Improve robustness of DUnit Testing by decreasing likelihood of port conflicts
Patrick Rhomberg created GEODE-5167:
---
Summary: Improve robustness of DUnit Testing by decreasing
likelihood of port conflicts
Key: GEODE-5167
URL: https://issues.apache.org/jira/browse/GEODE-5167
Project: Geode
Issue Type: Bug
Reporter: Patrick Rhomberg
Much of our DUnit framework begins members that ultimately reaches
{{o.a.g.internal.AvailablePort}} to choose a port on which the locator and
members will communicate. This class is naive and can return the same
randomly-chosen port across multiple requests. Though statistically rare, this
has proven not infrequent with our current rate of testing.
Possible amelioration: The possibility of collision could be reduced
significantly if the {{AvailablePort}} class retains the previous [N=20] ports
it has offered as available, refusing to offer as available a port it has
offered recently.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4218) load-cluster-configuration-from-dir is no longer required when setting --cluster-config-dir
[ https://issues.apache.org/jira/browse/GEODE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4218: -- Labels: pull-request-available (was: ) > load-cluster-configuration-from-dir is no longer required when setting > --cluster-config-dir > --- > > Key: GEODE-4218 > URL: https://issues.apache.org/jira/browse/GEODE-4218 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, management >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.6.0 > > > Currently if you start a locator with: > load-cluster-configuration-from-dir=true > you would usually need to specify a "cluster-configuration-dir" to go with > it, if you don't, it will default to the locator's working dir which is > usually empty, and when this happens, it will override the entire cluster's > configuration to be empty. > We have deprecated this option. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5166) NPE thrown from HARegionQueue.updateHAEventWrapper
[
https://issues.apache.org/jira/browse/GEODE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460309#comment-16460309
]
ASF subversion and git services commented on GEODE-5166:
Commit ed3d10c011417e1c7a7056d2716a8244ff235c5a in geode's branch
refs/heads/feature/GEODE-5166 from [~lhughesgodfrey]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=ed3d10c ]
GEODE-5166: NPE thrown while processing InitialImage of subscription region
* Fix NPE in updateHAEventWrapper
* Clean up code (renaming variables) in putEventInHARegion
* Removing old/commented out code
> NPE thrown from HARegionQueue.updateHAEventWrapper
> --
>
> Key: GEODE-5166
> URL: https://issues.apache.org/jira/browse/GEODE-5166
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
>
> NPE thrown when processing the InitialImage for an HARegionQueue
> {noformat}
> ERROR util.TestException:
> /var/vcap/data/vad/eventValidation_FullListFailOver-0430-070117/bridgegemfire4_19378/system.log
> contains java.lang.NullPointerException
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.ha.HARegionQueue.updateHAEventWrapper(HARegionQueue.java:2128)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.HARegion.updateHAEventWrapper(HARegion.java:481)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:825)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:977)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1307)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2786)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:832)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in java.lang.Thread.run(Thread.java:745)
> at
>
[jira] [Updated] (GEODE-5083) Alter region --name option no longer auto completes
[ https://issues.apache.org/jira/browse/GEODE-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5083: -- Labels: pull-request-available quick_to_fix (was: quick_to_fix) > Alter region --name option no longer auto completes > --- > > Key: GEODE-5083 > URL: https://issues.apache.org/jira/browse/GEODE-5083 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available, quick_to_fix > > when "alter region --name=" is typed, tabbing should show a list of available > regions -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5166) NPE thrown from HARegionQueue.updateHAEventWrapper
[
https://issues.apache.org/jira/browse/GEODE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shelley Lynn Hughes-Godfrey reassigned GEODE-5166:
--
Assignee: Shelley Lynn Hughes-Godfrey
> NPE thrown from HARegionQueue.updateHAEventWrapper
> --
>
> Key: GEODE-5166
> URL: https://issues.apache.org/jira/browse/GEODE-5166
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
>
> NPE thrown when processing the InitialImage for an HARegionQueue
> {noformat}
> ERROR util.TestException:
> /var/vcap/data/vad/eventValidation_FullListFailOver-0430-070117/bridgegemfire4_19378/system.log
> contains java.lang.NullPointerException
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.ha.HARegionQueue.updateHAEventWrapper(HARegionQueue.java:2128)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.HARegion.updateHAEventWrapper(HARegion.java:481)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:825)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:977)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1307)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2786)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in
> org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:832)
> at Remote Member
> 'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
> in java.lang.Thread.run(Thread.java:745)
> at
> org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:87)
> at
> org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:542)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1215)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1056)
>
[jira] [Created] (GEODE-5166) NPE thrown from HARegionQueue.updateHAEventWrapper
Shelley Lynn Hughes-Godfrey created GEODE-5166:
--
Summary: NPE thrown from HARegionQueue.updateHAEventWrapper
Key: GEODE-5166
URL: https://issues.apache.org/jira/browse/GEODE-5166
Project: Geode
Issue Type: Bug
Components: client queues
Reporter: Shelley Lynn Hughes-Godfrey
NPE thrown when processing the InitialImage for an HARegionQueue
{noformat}
ERROR util.TestException:
/var/vcap/data/vad/eventValidation_FullListFailOver-0430-070117/bridgegemfire4_19378/system.log
contains java.lang.NullPointerException
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.ha.HARegionQueue.updateHAEventWrapper(HARegionQueue.java:2128)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.HARegion.updateHAEventWrapper(HARegion.java:481)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:825)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:977)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1307)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2786)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:378)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:444)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in
org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:832)
at Remote Member
'rs-GEM-1666-scheduler(bridgegemfire4_rs-GEM-1666-scheduler_19378:19378):1028'
in java.lang.Thread.run(Thread.java:745)
at
org.apache.geode.distributed.internal.ReplyException.handleCause(ReplyException.java:87)
at
org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:542)
at
org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1215)
at
org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1056)
at
org.apache.geode.internal.cache.HARegion.initialize(HARegion.java:335)
at
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3085)
at
org.apache.geode.internal.cache.HARegion.getInstance(HARegion.java:255)
at
org.apache.geode.internal.cache.ha.HARegionQueue.createHARegion(HARegionQueue.java:389)
at
org.apache.geode.internal.cache.ha.HARegionQueue.(HARegionQueue.java:373)
[jira] [Updated] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-2542:
--
Labels: Flaky pull-request-available (was: Flaky)
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky, pull-request-available
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 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:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> 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
> 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] [Updated] (GEODE-845) DistTXExpiryJUnitTest.testRegionIdleExpiration
[
https://issues.apache.org/jira/browse/GEODE-845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-845:
-
Labels: CI Flaky pull-request-available (was: CI Flaky)
> DistTXExpiryJUnitTest.testRegionIdleExpiration
> --
>
> Key: GEODE-845
> URL: https://issues.apache.org/jira/browse/GEODE-845
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: xiaojian zhou
>Priority: Major
> Labels: CI, Flaky, pull-request-available
>
> Revision: 942b89e0b1591a6ccf9cefa4c0e3f5dba8bad34b
> buid 1447 IntegrationTest
> {noformat}
> java.lang.AssertionError: Expiration should not cause commit to fail
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.TXExpiryJUnitTest.generalRegionExpirationTest(TXExpiryJUnitTest.java:397)
> at
> com.gemstone.gemfire.TXExpiryJUnitTest.testRegionIdleExpiration(TXExpiryJUnitTest.java:335)
> 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:497)
> 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.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:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
>
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460242#comment-16460242 ] ASF subversion and git services commented on GEODE-4728: Commit 93e8fca3a26bff1518aea9692d6556d9c583ae5e in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=93e8fca ] GEODE-4728: Docs - correct ssl-enabled system property > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4966) Add Security Permissions for JDBC gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16431351#comment-16431351 ] Fred Krone edited comment on GEODE-4966 at 5/1/18 9:49 PM: --- We've updated the two wiki pages. [http://geode.apache.org/docs/guide/14/managing/security/implementing_authorization.html] should go into the same release with the JDBC release notes (currently targeting 1.8). was (Author: fkrone): We've updated the two wiki pages. We will assign to docs once we remove experimental tag. > Add Security Permissions for JDBC gfsh commands > --- > > Key: GEODE-4966 > URL: https://issues.apache.org/jira/browse/GEODE-4966 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Barbara Pruijn >Assignee: Joey McAllister >Priority: Major > > Please make sure security permissions are documented for the jdbc commands on > these pages: > [http://geode.apache.org/docs/guide/14/managing/security/implementing_authorization.html] > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security] > [https://cwiki.apache.org/confluence/display/GEODE/Finer%20grained%20security] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4966) Add Security Permissions for JDBC gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone reassigned GEODE-4966: - Assignee: Joey McAllister > Add Security Permissions for JDBC gfsh commands > --- > > Key: GEODE-4966 > URL: https://issues.apache.org/jira/browse/GEODE-4966 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Barbara Pruijn >Assignee: Joey McAllister >Priority: Major > > Please make sure security permissions are documented for the jdbc commands on > these pages: > [http://geode.apache.org/docs/guide/14/managing/security/implementing_authorization.html] > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security] > [https://cwiki.apache.org/confluence/display/GEODE/Finer%20grained%20security] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4966) Add Security Permissions for JDBC gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred Krone updated GEODE-4966: -- Component/s: (was: regions) > Add Security Permissions for JDBC gfsh commands > --- > > Key: GEODE-4966 > URL: https://issues.apache.org/jira/browse/GEODE-4966 > Project: Geode > Issue Type: Task > Components: docs >Reporter: Barbara Pruijn >Priority: Major > > Please make sure security permissions are documented for the jdbc commands on > these pages: > [http://geode.apache.org/docs/guide/14/managing/security/implementing_authorization.html] > [https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security] > [https://cwiki.apache.org/confluence/display/GEODE/Finer%20grained%20security] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5143) rename ClusterConfigurationService
[ https://issues.apache.org/jira/browse/GEODE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460189#comment-16460189 ] ASF subversion and git services commented on GEODE-5143: Commit 9ff634a1885cbef3bc7cef2cc0b76d61cb4d7e72 in geode's branch refs/heads/develop from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9ff634a ] GEODE-5143: rename ClusterConfigurationService to ConfigurationPersistenceService (#1869) > rename ClusterConfigurationService > -- > > Key: GEODE-5143 > URL: https://issues.apache.org/jira/browse/GEODE-5143 > Project: Geode > Issue Type: Sub-task > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > The term ClusterConfigurationService is ambiguous. People have grand ideas > about what it should do which is way outside of the current scope of making a > public API for retrieving and persisting cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4218) load-cluster-configuration-from-dir is no longer required when setting --cluster-config-dir
[ https://issues.apache.org/jira/browse/GEODE-4218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller reassigned GEODE-4218: -- Assignee: Karen Smoler Miller (was: Joey McAllister) > load-cluster-configuration-from-dir is no longer required when setting > --cluster-config-dir > --- > > Key: GEODE-4218 > URL: https://issues.apache.org/jira/browse/GEODE-4218 > Project: Geode > Issue Type: Improvement > Components: configuration, docs, management >Reporter: Jinmei Liao >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.6.0 > > > Currently if you start a locator with: > load-cluster-configuration-from-dir=true > you would usually need to specify a "cluster-configuration-dir" to go with > it, if you don't, it will default to the locator's working dir which is > usually empty, and when this happens, it will override the entire cluster's > configuration to be empty. > We have deprecated this option. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build
[
https://issues.apache.org/jira/browse/GEODE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-2542:
Comment: was deleted
(was: [~PivotalSarge] Where is the 10-second wait you see in this test? I only
see 60-second waits.)
> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
> Issue Type: Bug
> Components: locator
>Reporter: Kirk Lund
>Assignee: Brian Baynes
>Priority: Major
> Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> asf919.gq1.ygridcore.net with 5 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:280)
> at
> org.apache.geode.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
> 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
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
>
[jira] [Commented] (GEODE-4987) Add rebalancing tests with colocated PRs and AEQ (colocated region)
[ https://issues.apache.org/jira/browse/GEODE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460145#comment-16460145 ] ASF subversion and git services commented on GEODE-4987: Commit 985c9be68a6baf813a02244cad0eb54589e5bab4 in geode's branch refs/heads/feature/GEODE-4987 from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=985c9be ] GEODE-4987: Add rebalancing tests with colocated PRs and AEQ * Added new tests for colocated PRs and AEQ > Add rebalancing tests with colocated PRs and AEQ (colocated region) > > > Key: GEODE-4987 > URL: https://issues.apache.org/jira/browse/GEODE-4987 > Project: Geode > Issue Type: Test > Components: lucene >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > > Create tests to add colocated partitioned regions during rebalance to verify > co-located region does not hang. > Create similar test with AEQ (which is a colocated region) to verify that > mutating region to add AEQ does not hang during rebalance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5155) hang recovering transaction state for crashed server
[
https://issues.apache.org/jira/browse/GEODE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-5155.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> hang recovering transaction state for crashed server
>
>
> Key: GEODE-5155
> URL: https://issues.apache.org/jira/browse/GEODE-5155
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service, transactions
>Affects Versions: 1.7.0
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A concourse job failed in
> DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict with
> two threads stuck in this state:
> {noformat}[vm2] "Pooled Waiting Message Processor 2" tid=0x71
> [vm2] java.lang.Thread.State: WAITING
> [vm2] at java.lang.Object.wait(Native Method)
> [vm2] - waiting on
> org.apache.geode.internal.cache.TXCommitMessage@2105ce6
> [vm2] at java.lang.Object.wait(Object.java:502)
> [vm2] at
> org.apache.geode.internal.cache.TXFarSideCMTracker.waitToProcess(TXFarSideCMTracker.java:176)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage.processTXOriginatorRecoveryMessage(TXOriginatorRecoveryProcessor.java:160)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage$1.run(TXOriginatorRecoveryProcessor.java:144)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run(ClusterDistributionManager.java:865)
> [vm2] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I modified the test to tighten up its forcedDisconnect and performOps methods
> to get transaction recovery to happen more reliably.
> {code}
> public void forceDisconnect() throws Exception {
> Cache existingCache = basicGetCache();
> synchronized(commitLock) {
> committing = false;
> while (!committing) {
> commitLock.wait();
> }
> }
> if (existingCache != null && !existingCache.isClosed()) {
>
> DistributedTestUtils.crashDistributedSystem(getCache().getDistributedSystem());
> }
> }
> public void performOps() {
> Cache cache = getCache();
> Region region = cache.getRegion("TestRegion");
> DistributedLockService dlockService =
> DistributedLockService.getServiceNamed("Bulldog");
> Random random = new Random();
> while (!cache.isClosed()) {
> boolean locked = false;
> try {
> locked = dlockService.lock("testDLock", 500, 60_000);
> if (!locked) {
> // this could happen if we're starved out for 30sec by other VMs
> continue;
> }
> cache.getCacheTransactionManager().begin();
> region.put("TestKey", "TestValue" + random.nextInt(10));
> TXManagerImpl mgr = (TXManagerImpl)
> getCache().getCacheTransactionManager();
> TXStateProxyImpl txProxy = (TXStateProxyImpl) mgr.getTXState();
> TXState txState = (TXState) txProxy.getRealDeal(null, null);
> txState.setBeforeSend(() -> {
> synchronized(commitLock) {
> committing = true;
> commitLock.notifyAll();
> }});
> try {
> cache.getCacheTransactionManager().commit();
> } catch (CommitConflictException e) {
> throw new RuntimeException("dlock failed to prevent a transaction
> conflict", e);
> }
> int txCount = getBlackboard().getMailbox(TRANSACTION_COUNT);
> getBlackboard().setMailbox(TRANSACTION_COUNT, txCount + 1);
> } catch (CancelException | IllegalStateException e) {
> // okay to ignore
> } finally {
> if (locked) {
> try {
> dlockService.unlock("testDLock");
> } catch (CancelException | IllegalStateException e) {
> // shutting down
> }
> }
> }
> }
> }
> {code}
> The problem is that the membership listener in TXCommitMessage is removing
> itself from the transaction map in TXFarSideCMTracker without setting any
> state that the recovery message can
[jira] [Closed] (GEODE-5155) hang recovering transaction state for crashed server
[
https://issues.apache.org/jira/browse/GEODE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt closed GEODE-5155.
---
> hang recovering transaction state for crashed server
>
>
> Key: GEODE-5155
> URL: https://issues.apache.org/jira/browse/GEODE-5155
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service, transactions
>Affects Versions: 1.7.0
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> A concourse job failed in
> DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict with
> two threads stuck in this state:
> {noformat}[vm2] "Pooled Waiting Message Processor 2" tid=0x71
> [vm2] java.lang.Thread.State: WAITING
> [vm2] at java.lang.Object.wait(Native Method)
> [vm2] - waiting on
> org.apache.geode.internal.cache.TXCommitMessage@2105ce6
> [vm2] at java.lang.Object.wait(Object.java:502)
> [vm2] at
> org.apache.geode.internal.cache.TXFarSideCMTracker.waitToProcess(TXFarSideCMTracker.java:176)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage.processTXOriginatorRecoveryMessage(TXOriginatorRecoveryProcessor.java:160)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage$1.run(TXOriginatorRecoveryProcessor.java:144)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run(ClusterDistributionManager.java:865)
> [vm2] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I modified the test to tighten up its forcedDisconnect and performOps methods
> to get transaction recovery to happen more reliably.
> {code}
> public void forceDisconnect() throws Exception {
> Cache existingCache = basicGetCache();
> synchronized(commitLock) {
> committing = false;
> while (!committing) {
> commitLock.wait();
> }
> }
> if (existingCache != null && !existingCache.isClosed()) {
>
> DistributedTestUtils.crashDistributedSystem(getCache().getDistributedSystem());
> }
> }
> public void performOps() {
> Cache cache = getCache();
> Region region = cache.getRegion("TestRegion");
> DistributedLockService dlockService =
> DistributedLockService.getServiceNamed("Bulldog");
> Random random = new Random();
> while (!cache.isClosed()) {
> boolean locked = false;
> try {
> locked = dlockService.lock("testDLock", 500, 60_000);
> if (!locked) {
> // this could happen if we're starved out for 30sec by other VMs
> continue;
> }
> cache.getCacheTransactionManager().begin();
> region.put("TestKey", "TestValue" + random.nextInt(10));
> TXManagerImpl mgr = (TXManagerImpl)
> getCache().getCacheTransactionManager();
> TXStateProxyImpl txProxy = (TXStateProxyImpl) mgr.getTXState();
> TXState txState = (TXState) txProxy.getRealDeal(null, null);
> txState.setBeforeSend(() -> {
> synchronized(commitLock) {
> committing = true;
> commitLock.notifyAll();
> }});
> try {
> cache.getCacheTransactionManager().commit();
> } catch (CommitConflictException e) {
> throw new RuntimeException("dlock failed to prevent a transaction
> conflict", e);
> }
> int txCount = getBlackboard().getMailbox(TRANSACTION_COUNT);
> getBlackboard().setMailbox(TRANSACTION_COUNT, txCount + 1);
> } catch (CancelException | IllegalStateException e) {
> // okay to ignore
> } finally {
> if (locked) {
> try {
> dlockService.unlock("testDLock");
> } catch (CancelException | IllegalStateException e) {
> // shutting down
> }
> }
> }
> }
> }
> {code}
> The problem is that the membership listener in TXCommitMessage is removing
> itself from the transaction map in TXFarSideCMTracker without setting any
> state that the recovery message can check. The recovery method is waiting
> like this:
[jira] [Commented] (GEODE-5155) hang recovering transaction state for crashed server
[
https://issues.apache.org/jira/browse/GEODE-5155?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460120#comment-16460120
]
ASF subversion and git services commented on GEODE-5155:
Commit 2a02923a2fe3ead102ff79e76c47935e84f76859 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2a02923 ]
GEODE-5155 hang recovering transaction state for crashed server
The fix is to check to see if the message was removed due to a
memberDeparted event.
When that happens a departureNoticed flag was being set in TXCommitMessage
but the wait loop in the transaction tracker wasn't checking this flag.
> hang recovering transaction state for crashed server
>
>
> Key: GEODE-5155
> URL: https://issues.apache.org/jira/browse/GEODE-5155
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service, transactions
>Affects Versions: 1.7.0
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A concourse job failed in
> DlockAndTxlockRegressionTest.testDLockProtectsAgainstTransactionConflict with
> two threads stuck in this state:
> {noformat}[vm2] "Pooled Waiting Message Processor 2" tid=0x71
> [vm2] java.lang.Thread.State: WAITING
> [vm2] at java.lang.Object.wait(Native Method)
> [vm2] - waiting on
> org.apache.geode.internal.cache.TXCommitMessage@2105ce6
> [vm2] at java.lang.Object.wait(Object.java:502)
> [vm2] at
> org.apache.geode.internal.cache.TXFarSideCMTracker.waitToProcess(TXFarSideCMTracker.java:176)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage.processTXOriginatorRecoveryMessage(TXOriginatorRecoveryProcessor.java:160)
> [vm2] at
> org.apache.geode.internal.cache.locks.TXOriginatorRecoveryProcessor$TXOriginatorRecoveryMessage$1.run(TXOriginatorRecoveryProcessor.java:144)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm2] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1121)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:109)
> [vm2] at
> org.apache.geode.distributed.internal.ClusterDistributionManager$6$1.run(ClusterDistributionManager.java:865)
> [vm2] at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I modified the test to tighten up its forcedDisconnect and performOps methods
> to get transaction recovery to happen more reliably.
> {code}
> public void forceDisconnect() throws Exception {
> Cache existingCache = basicGetCache();
> synchronized(commitLock) {
> committing = false;
> while (!committing) {
> commitLock.wait();
> }
> }
> if (existingCache != null && !existingCache.isClosed()) {
>
> DistributedTestUtils.crashDistributedSystem(getCache().getDistributedSystem());
> }
> }
> public void performOps() {
> Cache cache = getCache();
> Region region = cache.getRegion("TestRegion");
> DistributedLockService dlockService =
> DistributedLockService.getServiceNamed("Bulldog");
> Random random = new Random();
> while (!cache.isClosed()) {
> boolean locked = false;
> try {
> locked = dlockService.lock("testDLock", 500, 60_000);
> if (!locked) {
> // this could happen if we're starved out for 30sec by other VMs
> continue;
> }
> cache.getCacheTransactionManager().begin();
> region.put("TestKey", "TestValue" + random.nextInt(10));
> TXManagerImpl mgr = (TXManagerImpl)
> getCache().getCacheTransactionManager();
> TXStateProxyImpl txProxy = (TXStateProxyImpl) mgr.getTXState();
> TXState txState = (TXState) txProxy.getRealDeal(null, null);
> txState.setBeforeSend(() -> {
> synchronized(commitLock) {
> committing = true;
> commitLock.notifyAll();
> }});
> try {
> cache.getCacheTransactionManager().commit();
> } catch (CommitConflictException e) {
> throw new RuntimeException("dlock failed to prevent a transaction
> conflict", e);
> }
> int txCount = getBlackboard().getMailbox(TRANSACTION_COUNT);
> getBlackboard().setMailbox(TRANSACTION_COUNT, txCount + 1);
> } catch (CancelException | IllegalStateException e) {
> // okay to ignore
>
[jira] [Commented] (GEODE-4987) Add rebalancing tests with colocated PRs and AEQ (colocated region)
[ https://issues.apache.org/jira/browse/GEODE-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460094#comment-16460094 ] ASF subversion and git services commented on GEODE-4987: Commit bbe9e3cd6dc87fe9981deeed9998ceddb35309e8 in geode's branch refs/heads/feature/GEODE-4987 from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=bbe9e3c ] GEODE-4987: Add rebalancing tests with colocated PRs and AEQ * Added new tests for colocated PRs and AEQ > Add rebalancing tests with colocated PRs and AEQ (colocated region) > > > Key: GEODE-4987 > URL: https://issues.apache.org/jira/browse/GEODE-4987 > Project: Geode > Issue Type: Test > Components: lucene >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > > Create tests to add colocated partitioned regions during rebalance to verify > co-located region does not hang. > Create similar test with AEQ (which is a colocated region) to verify that > mutating region to add AEQ does not hang during rebalance. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5165) Avoid OOME when scanning for annotated classes
[ https://issues.apache.org/jira/browse/GEODE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5165: -- Labels: pull-request-available (was: ) > Avoid OOME when scanning for annotated classes > -- > > Key: GEODE-5165 > URL: https://issues.apache.org/jira/browse/GEODE-5165 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > > when we scan the entire classpath for a certain annotated class, we ran into > OOME in our test environment. Need to add a capability to limit the packages > to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5165) Avoid OOME when scanning for annotated classes
Jinmei Liao created GEODE-5165: -- Summary: Avoid OOME when scanning for annotated classes Key: GEODE-5165 URL: https://issues.apache.org/jira/browse/GEODE-5165 Project: Geode Issue Type: Bug Components: configuration Reporter: Jinmei Liao when we scan the entire classpath for a certain annotated class, we ran into OOME in our test environment. Need to add a capability to limit the packages to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5165) Avoid OOME when scanning for annotated classes
[ https://issues.apache.org/jira/browse/GEODE-5165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao reassigned GEODE-5165: -- Assignee: Jinmei Liao > Avoid OOME when scanning for annotated classes > -- > > Key: GEODE-5165 > URL: https://issues.apache.org/jira/browse/GEODE-5165 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > > when we scan the entire classpath for a certain annotated class, we ran into > OOME in our test environment. Need to add a capability to limit the packages > to scan if geode.packagesToScan system property is set. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5152) add unit test coverage for AbstractRegionMap.txApplyPut
[ https://issues.apache.org/jira/browse/GEODE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-5152. - Resolution: Fixed Fix Version/s: 1.7.0 > add unit test coverage for AbstractRegionMap.txApplyPut > --- > > Key: GEODE-5152 > URL: https://issues.apache.org/jira/browse/GEODE-5152 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: AbstractRegionMap, pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > AbstractRegionMapTest has some coverage for txApplyPut but a large section of > the method has no coverage. The while loop that handles a non-null "oldRe" is > never executed. > Also, it is never called with an owner that > "isUsedForPartitionedRegionBucket()". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5152) add unit test coverage for AbstractRegionMap.txApplyPut
[ https://issues.apache.org/jira/browse/GEODE-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460056#comment-16460056 ] ASF subversion and git services commented on GEODE-5152: Commit 7b9e8c21c6af53e90b7084571010af76e51852ab in geode's branch refs/heads/develop from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7b9e8c2 ] GEODE-5152: add unit tests for txApplyPut (#1889) > add unit test coverage for AbstractRegionMap.txApplyPut > --- > > Key: GEODE-5152 > URL: https://issues.apache.org/jira/browse/GEODE-5152 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: AbstractRegionMap, pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > AbstractRegionMapTest has some coverage for txApplyPut but a large section of > the method has no coverage. The while loop that handles a non-null "oldRe" is > never executed. > Also, it is never called with an owner that > "isUsedForPartitionedRegionBucket()". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5164) refactor the three blocks of code in txApplyPut into one method
[ https://issues.apache.org/jira/browse/GEODE-5164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-5164: --- Assignee: Darrel Schneider > refactor the three blocks of code in txApplyPut into one method > --- > > Key: GEODE-5164 > URL: https://issues.apache.org/jira/browse/GEODE-5164 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > AbstractRegionMap.txApplyPut currently has three blocks of code that do the > put: > 1. applyTxUpdateOnReplicateOrRedundantCopy is called and much of the code in > it is the same as the oldRe block > 2. oldRe block: if an existing entry is found, do the put by changing it > 3. newRe block: if no existing entry is found, create a new entry and do the > put by changing it > It would help future refactoring of txApplyPut if these 3 blocks of code > could be consolidated into a single method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5164) refactor the three blocks of code in txApplyPut into one method
Darrel Schneider created GEODE-5164: --- Summary: refactor the three blocks of code in txApplyPut into one method Key: GEODE-5164 URL: https://issues.apache.org/jira/browse/GEODE-5164 Project: Geode Issue Type: Sub-task Components: transactions Reporter: Darrel Schneider AbstractRegionMap.txApplyPut currently has three blocks of code that do the put: 1. applyTxUpdateOnReplicateOrRedundantCopy is called and much of the code in it is the same as the oldRe block 2. oldRe block: if an existing entry is found, do the put by changing it 3. newRe block: if no existing entry is found, create a new entry and do the put by changing it It would help future refactoring of txApplyPut if these 3 blocks of code could be consolidated into a single method. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5163) Tests extending PulseAcceptanceTestBase are flaky
Patrick Rhomberg created GEODE-5163: --- Summary: Tests extending PulseAcceptanceTestBase are flaky Key: GEODE-5163 URL: https://issues.apache.org/jira/browse/GEODE-5163 Project: Geode Issue Type: Bug Components: pulse Reporter: Patrick Rhomberg See these Concourse runs for more context: https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/208 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testDataViewTreeMapPopUpData https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/217 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/231 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/249 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/256 org.apache.geode.tools.pulse.ui.PulseAcceptanceAuthTest > testClusterDetailsAndWidgets https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/UITests/builds/258 org.apache.geode.tools.pulse.ui.PulseAcceptanceNoAuthTest > testClusterDetailsAndWidgets -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5161) Accessing cacheImpl directly to avoid more access exceptions
[ https://issues.apache.org/jira/browse/GEODE-5161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5161: -- Labels: pull-request-available (was: ) > Accessing cacheImpl directly to avoid more access exceptions > > > Key: GEODE-5161 > URL: https://issues.apache.org/jira/browse/GEODE-5161 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Ryan McMahon >Priority: Major > Labels: pull-request-available > > The testCacheXmlInitialization test results in a race condition between cache > destruction and cache access in two different threads. Accessing the > CacheImpl directly instead of the Cache appears to work around the race > condtion. Another story will be written to address the actual race condition > but this story captures the quick test fix of accessing CacheImpl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5162) Race condition between cache destruction and background thread cache access
Ryan McMahon created GEODE-5162: --- Summary: Race condition between cache destruction and background thread cache access Key: GEODE-5162 URL: https://issues.apache.org/jira/browse/GEODE-5162 Project: Geode Issue Type: Bug Components: native client Reporter: Ryan McMahon A race condition exists where the cache is accessed after it has been destroyed in one of the many background threads created for various reasons (failover, cleanup, periodic acks, etc). TcrConnectionManager.startFailoverAndCleanupThreads() ThinClientPoolHADM.startBackgroundThreads() HostSampler.start() There are probably other places where background threads are spun up as well, but these are the ones that were found in our tests. There is no synchronization between these background threads and the thread which destroys the cache, so it is possible that the background threads access the cache after destruction. We should investigate a robust way of synchronizing between the thread that creates/destroys the cache and the background threads, or evaluate if we can eliminate the dependency on the cache in the background threads. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5161) Accessing cacheImpl directly to avoid more access exceptions
Ryan McMahon created GEODE-5161: --- Summary: Accessing cacheImpl directly to avoid more access exceptions Key: GEODE-5161 URL: https://issues.apache.org/jira/browse/GEODE-5161 Project: Geode Issue Type: Test Components: native client Reporter: Ryan McMahon The testCacheXmlInitialization test results in a race condition between cache destruction and cache access in two different threads. Accessing the CacheImpl directly instead of the Cache appears to work around the race condtion. Another story will be written to address the actual race condition but this story captures the quick test fix of accessing CacheImpl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4606) Create new geode-example about continuous queries
[ https://issues.apache.org/jira/browse/GEODE-4606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-4606: Assignee: (was: Michael Dodge) > Create new geode-example about continuous queries > - > > Key: GEODE-4606 > URL: https://issues.apache.org/jira/browse/GEODE-4606 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Create an example the demonstrates continuous queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5153) Remove use of internal distributed system and log writer utils from IgnoredException
[
https://issues.apache.org/jira/browse/GEODE-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459890#comment-16459890
]
ASF subversion and git services commented on GEODE-5153:
Commit cf3fc6cb741472b78dac7e258680f8a201c9c5cd in geode's branch
refs/heads/develop from [~PivotalSarge]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf3fc6c ]
GEODE-5153: Remove uses of the internal distributed system's log writer and the
log writer utils' log writer. (#1887)
> Remove use of internal distributed system and log writer utils from
> IgnoredException
>
>
> Key: GEODE-5153
> URL: https://issues.apache.org/jira/browse/GEODE-5153
> Project: Geode
> Issue Type: Improvement
> Components: general
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In {{IgnoredException}}, the internal distributed system's log writer and the
> log writer utils' log writer are used to log add and remove messages. These
> uses have comments that say {{TODO}} and indicate that the uses should be
> removed. Since the log service's logger is already used to log add and remove
> messages, remove the use of the internal distributed system's log writer and
> the log writer utils' log writer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5153) Remove use of internal distributed system and log writer utils from IgnoredException
[
https://issues.apache.org/jira/browse/GEODE-5153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dodge resolved GEODE-5153.
--
Resolution: Fixed
Fix Version/s: 1.7.0
> Remove use of internal distributed system and log writer utils from
> IgnoredException
>
>
> Key: GEODE-5153
> URL: https://issues.apache.org/jira/browse/GEODE-5153
> Project: Geode
> Issue Type: Improvement
> Components: general
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> In {{IgnoredException}}, the internal distributed system's log writer and the
> log writer utils' log writer are used to log add and remove messages. These
> uses have comments that say {{TODO}} and indicate that the uses should be
> removed. Since the log service's logger is already used to log add and remove
> messages, remove the use of the internal distributed system's log writer and
> the log writer utils' log writer.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-924) CI failure: ShorteningExpirationTimeRegressionTest.testGet
[
https://issues.apache.org/jira/browse/GEODE-924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-924:
-
Labels: CI Flaky pull-request-available (was: CI Flaky)
> CI failure: ShorteningExpirationTimeRegressionTest.testGet
> --
>
> Key: GEODE-924
> URL: https://issues.apache.org/jira/browse/GEODE-924
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: Sai Boorlagadda
>Priority: Major
> Labels: CI, Flaky, pull-request-available
>
> {noformat}
> Error Message
> java.lang.AssertionError: 1 ms expire did not happen after waiting 1000 ms
> Stacktrace
> java.lang.AssertionError: 1 ms expire did not happen after waiting 1000 ms
> at org.junit.Assert.fail(Assert.java:88)
> at
> com.gemstone.gemfire.cache30.Bug44418JUnitTest.testGet(Bug44418JUnitTest.java:145)
> 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:497)
> 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.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:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> 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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
>
[jira] [Commented] (GEODE-5111) show missing-disk-stores sometimes does not show the missing disk stores
[ https://issues.apache.org/jira/browse/GEODE-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459851#comment-16459851 ] ASF subversion and git services commented on GEODE-5111: Commit 1f77a603e5766ed14e980c2ca52902219c2bdab0 in geode's branch refs/heads/develop from [~demery] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1f77a60 ] GEODE-5111: Set offline members to null only when done waiting for them (#1873) * GEODE-5111: Set offline members to null only when done waiting for them > show missing-disk-stores sometimes does not show the missing disk stores > > > Key: GEODE-5111 > URL: https://issues.apache.org/jira/browse/GEODE-5111 > Project: Geode > Issue Type: Bug >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > Labels: persistence, pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > When geode logs are showing there is in fact a missing disk store, running > the show-missing-disk-store command sometimes returns that there are no > missing disk stores -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5111) show missing-disk-stores sometimes does not show the missing disk stores
[ https://issues.apache.org/jira/browse/GEODE-5111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459850#comment-16459850 ] ASF subversion and git services commented on GEODE-5111: Commit 1f77a603e5766ed14e980c2ca52902219c2bdab0 in geode's branch refs/heads/develop from [~demery] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1f77a60 ] GEODE-5111: Set offline members to null only when done waiting for them (#1873) * GEODE-5111: Set offline members to null only when done waiting for them > show missing-disk-stores sometimes does not show the missing disk stores > > > Key: GEODE-5111 > URL: https://issues.apache.org/jira/browse/GEODE-5111 > Project: Geode > Issue Type: Bug >Reporter: Lynn Gallinat >Assignee: Lynn Gallinat >Priority: Major > Labels: persistence, pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > When geode logs are showing there is in fact a missing disk store, running > the show-missing-disk-store command sometimes returns that there are no > missing disk stores -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5131) CI failure: org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDUnitTest > testParallelPropagationSenderResume FAILED
[
https://issues.apache.org/jira/browse/GEODE-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-5131:
--
Labels: pull-request-available (was: )
> CI failure:
> org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDUnitTest
> > testParallelPropagationSenderResume FAILED
>
>
> Key: GEODE-5131
> URL: https://issues.apache.org/jira/browse/GEODE-5131
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.7.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Labels: pull-request-available
>
> This failure occurred during CI on develop:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/296
> {noformat}
> org.apache.geode.internal.cache.wan.offheap.ParallelGatewaySenderOperationsOffHeapDUnitTest
> > testParallelPropagationSenderResume FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$79/470558236.run
> in VM 4 running on Host 1f5f8948cda6 with 8 VMs
> Caused by:
> java.lang.AssertionError: Expected events in all primary queues after
> drain is 0 expected:<0> but was:<1>
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5143) rename ClusterConfigurationService
[ https://issues.apache.org/jira/browse/GEODE-5143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-5143: --- Component/s: docs > rename ClusterConfigurationService > -- > > Key: GEODE-5143 > URL: https://issues.apache.org/jira/browse/GEODE-5143 > Project: Geode > Issue Type: Sub-task > Components: configuration, docs >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The term ClusterConfigurationService is ambiguous. People have grand ideas > about what it should do which is way outside of the current scope of making a > public API for retrieving and persisting cluster configuration. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-2668) Add gfsh command to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-2668:
---
Assignee: Kenneth Howe
> Add gfsh command to destroy gateway receiver
>
>
> Key: GEODE-2668
> URL: https://issues.apache.org/jira/browse/GEODE-2668
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, there is a {{create gateway-receiver}} command, but no
> corresponding destroy command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
