[jira] [Commented] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)

2019-06-19 Thread Donal Evans (JIRA)


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

Donal Evans commented on GEODE-5816:


Possible reoccurrence: 
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/821]

> ClusterStartupRule fails to launch JMX manager (port already in use)
> 
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Bill Burcham
>Assignee: Dan Smith
>Priority: Major
>  Labels: CI, swat
>
> We see these related failures on a couple tests in 
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs 
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs 
> before the tests run, we think the problem lies outside the 
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
>   4 failures (99.600% success 
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
>  |  .testAddRmNewMemberWithReplicatedRegionsAndSubregions:  1 failures 
> (99.900% success rate)
>  |   |  Failed build 24   at 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
>  |  .testMultiplePartitionedRegions:  3 failures (99.700% success rate)
>  |   |  Failed build 982  at 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
>  |   |  Failed build 256  at 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC  
> tid=0x20] Jmx manager could not be started because 
> java.rmi.server.ExportException: Port already in use: 25305; nested exception 
> is: 
>   java.net.BindException: Failed to create server socket on  
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException: 
> java.rmi.server.ExportException: Port already in use: 25305; nested exception 
> is: 
>   java.net.BindException: Failed to create server socket on  
> ffd50f3577c5/172.17.0.20[25305]
>   at 
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
>   at 
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
>   at 
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
>   at 
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
>   at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
>   at 
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
>   at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
>   at 
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
>   at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
>   at 
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
>   at 
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
>   at 
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:68)
>   at 
> org.apache.geode.test.dunit.rules.ClusterStartupRule.lambda$startLocatorVM$22d9b8a8$1(ClusterStartupRule.java:206)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> 

[jira] [Created] (GEODE-7154) Scripts fail with "Too many authentication failures"

2019-09-03 Thread Donal Evans (Jira)
Donal Evans created GEODE-7154:
--

 Summary: Scripts fail with "Too many authentication failures"
 Key: GEODE-7154
 URL: https://issues.apache.org/jira/browse/GEODE-7154
 Project: Geode
  Issue Type: Bug
  Components: benchmarks
Reporter: Donal Evans


When using the run_tests.sh script, the connection fails due to too many 
authentication failures, ultimately caused by offering too many authentication 
keys to the server:

{noformat}./run_tests.sh -t pdxTestCluster --br DonalEvans/geode-benchmarks 
--bb feature/AddPdxTypeBenchmark --output 
~/benchmarking/PDXTypeBenchmark/baseline -- --tests=CreatePdxFromJSONBenchmark
FIRST_INSTANCE=52.43.142.66
HOSTS=172.31.45.135,172.31.42.61,172.31.40.26,172.31.44.175
Warning: Permanently added '52.43.142.66' (ECDSA) to the list of known hosts.
Received disconnect from 52.43.142.66 port 22:2: Too many authentication 
failures
Disconnected from 52.43.142.66 port 22{noformat}





--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (GEODE-7115) CI Failure: CreateRegionCommandPersistsConfigurationDUnitTest > createRegionWithColocation

2019-08-22 Thread Donal Evans (Jira)
Donal Evans created GEODE-7115:
--

 Summary: CI Failure: 
CreateRegionCommandPersistsConfigurationDUnitTest > createRegionWithColocation
 Key: GEODE-7115
 URL: https://issues.apache.org/jira/browse/GEODE-7115
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Donal Evans


https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1015

org.apache.geode.management.internal.cli.commands.CreateRegionCommandPersistsConfigurationDUnitTest
 > createRegionWithColocation FAILED
org.junit.ComparisonFailure: [Specify a valid region path for 
colocated-with. Region /createRegionWithColocation not found.
] expected:<[OK]> but was:<[ERROR]>
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.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
at 
org.apache.geode.management.internal.cli.commands.CreateRegionCommandPersistsConfigurationDUnitTest.createRegionWithColocation(CreateRegionCommandPersistsConfigurationDUnitTest.java:442)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (GEODE-7117) CI Failure: AlterRegionCommandDUnitTest > alterEntryIdleTimeExpirationAction

2019-08-22 Thread Donal Evans (Jira)
Donal Evans created GEODE-7117:
--

 Summary: CI Failure: AlterRegionCommandDUnitTest > 
alterEntryIdleTimeExpirationAction
 Key: GEODE-7117
 URL: https://issues.apache.org/jira/browse/GEODE-7117
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Donal Evans


https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1019

org.apache.geode.management.internal.cli.commands.AlterRegionCommandDUnitTest > 
alterEntryIdleTimeExpirationAction FAILED
org.junit.ComparisonFailure: [Error while processing command  Reason : null
] expected:<[OK]> but was:<[ERROR]>
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.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:104)
at 
org.apache.geode.management.internal.cli.commands.AlterRegionCommandDUnitTest.alterEntryIdleTimeExpirationAction(AlterRegionCommandDUnitTest.java:171)

org.apache.geode.management.internal.cli.commands.AlterRegionCommandDUnitTest > 
classMethod FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 4231

[error 2019/08/22 18:09:01.084 GMT  
tid=101] Could not execute "create region --name=regionA --type=REPLICATE 
--entry-idle-time-expiration-action=destroy --enable-statistics".
java.lang.reflect.UndeclaredThrowableException
at com.sun.proxy.$Proxy80.getRegionType(Unknown Source)
at 
org.apache.geode.management.internal.beans.DistributedRegionBridge.getEmptyNodes(DistributedRegionBridge.java:643)
at 
org.apache.geode.management.internal.beans.DistributedRegionMBean.getEmptyNodes(DistributedRegionMBean.java:315)
at 
org.apache.geode.management.internal.cli.commands.CreateRegionCommand.failIfRegionAlreadyExists(CreateRegionCommand.java:623)
at 
org.apache.geode.management.internal.cli.commands.CreateRegionCommand.createRegion(CreateRegionCommand.java:201)
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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:215)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.callInvokeMethod(CommandExecutor.java:138)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:148)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:76)
at 
org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:61)
at 
org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:124)
at 
org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1254)
at 
org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:419)
at sun.reflect.GeneratedMethodAccessor155.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
at 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at 

[jira] [Issue Comment Deleted] (GEODE-6070) CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll

2019-08-22 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-6070:
---
Comment: was deleted

(was: 
https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK8/builds/905)

> CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll
> --
>
> Key: GEODE-6070
> URL: https://issues.apache.org/jira/browse/GEODE-6070
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: GeodeCommons
>
> Failed with stacktrace:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest
>  > testShutdownAll FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 302
> org.apache.geode.distributed.DistributedSystemDisconnectedException: 
> Distribution manager on 172.17.0.3(server-1:496):41002 started at Thu Nov 
> 15 19:47:58 UTC 2018: Message distribution has terminated
> {noformat}
> Test results can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-results/distributedTest/1542315851/classes/org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest.html#testShutdownAll
>  
> Test Artifacts can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-artifacts/1542315851/distributedtestfiles-OpenJDK8-1.9.0-build.158.tgz



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (GEODE-7116) CI Failure: PartitionedRegionSingleHopDUnitTest > testServerLocationRemovalThroughPing

2019-08-22 Thread Donal Evans (Jira)
Donal Evans created GEODE-7116:
--

 Summary: CI Failure: PartitionedRegionSingleHopDUnitTest > 
testServerLocationRemovalThroughPing
 Key: GEODE-7116
 URL: https://issues.apache.org/jira/browse/GEODE-7116
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1008

org.apache.geode.internal.cache.PartitionedRegionSingleHopDUnitTest > 
testServerLocationRemovalThroughPing FAILED
java.lang.AssertionError: expected:<4> but was:<0>
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.cache.PartitionedRegionSingleHopDUnitTest.testServerLocationRemovalThroughPing(PartitionedRegionSingleHopDUnitTest.java:679)



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Commented] (GEODE-6070) CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll

2019-08-22 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-6070:


https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK8/builds/905

> CI Failure: ShutdownCommandOverHttpDUnitTest > testShutdownAll
> --
>
> Key: GEODE-6070
> URL: https://issues.apache.org/jira/browse/GEODE-6070
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Patrick Rhomberg
>Priority: Major
>  Labels: GeodeCommons
>
> Failed with stacktrace:
> {noformat}
> org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest
>  > testShutdownAll FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 302
> org.apache.geode.distributed.DistributedSystemDisconnectedException: 
> Distribution manager on 172.17.0.3(server-1:496):41002 started at Thu Nov 
> 15 19:47:58 UTC 2018: Message distribution has terminated
> {noformat}
> Test results can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-results/distributedTest/1542315851/classes/org.apache.geode.management.internal.cli.commands.ShutdownCommandOverHttpDUnitTest.html#testShutdownAll
>  
> Test Artifacts can be found here:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.158/test-artifacts/1542315851/distributedtestfiles-OpenJDK8-1.9.0-build.158.tgz



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Assigned] (GEODE-7035) pdx enum registry needs to be improved

2019-09-09 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7035:
--

Assignee: Donal Evans

> pdx enum registry needs to be improved
> --
>
> Key: GEODE-7035
> URL: https://issues.apache.org/jira/browse/GEODE-7035
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Darrel Schneider
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> The work done for pdx types in GEODE-6973 revealed that we have similar 
> issues with enum's serialized by pdx.
>  # The enumToId map should be populated at the same time the typeToId map is.
>  # afterCreate on the CacheListener should also update the enumToId map.
>  # duplicate code exists for enumToId that could be refactored to share code 
> that maintains typeToId.
>  #



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Resolved] (GEODE-7204) Add documentation for Asynchronous Event Queue pause-event-processing configuration

2019-09-17 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7204.

Fix Version/s: 1.10.0
   Resolution: Fixed

> Add documentation for Asynchronous Event Queue pause-event-processing 
> configuration
> ---
>
> Key: GEODE-7204
> URL: https://issues.apache.org/jira/browse/GEODE-7204
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Benjamin P Ross
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With the work done for https://issues.apache.org/jira/browse/GEODE-7121 we've 
> added the new configuration attribute to Async Event Queues. We should add 
> references to this in our documentation for cache-xml, the 
> AsyncEventQueueFactory class, and the create/alter async-event-queue commands.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Assigned] (GEODE-7204) Add documentation for Asynchronous Event Queue pause-event-processing configuration

2019-09-17 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7204:
--

Assignee: Donal Evans

> Add documentation for Asynchronous Event Queue pause-event-processing 
> configuration
> ---
>
> Key: GEODE-7204
> URL: https://issues.apache.org/jira/browse/GEODE-7204
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Benjamin P Ross
>Assignee: Donal Evans
>Priority: Major
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> With the work done for https://issues.apache.org/jira/browse/GEODE-7121 we've 
> added the new configuration attribute to Async Event Queues. We should add 
> references to this in our documentation for cache-xml, the 
> AsyncEventQueueFactory class, and the create/alter async-event-queue commands.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


[jira] [Created] (GEODE-7032) CI Failure: PartitionedRegionCreationJUnitTest hangs while trying to create partitioned region

2019-07-30 Thread Donal Evans (JIRA)
Donal Evans created GEODE-7032:
--

 Summary: CI Failure: PartitionedRegionCreationJUnitTest hangs 
while trying to create partitioned region
 Key: GEODE-7032
 URL: https://issues.apache.org/jira/browse/GEODE-7032
 Project: Geode
  Issue Type: Bug
  Components: distributed lock service
Reporter: Donal Evans


> Task :geode-core:integrationTest

timeout exceeded

=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0485/test-results/integrationTest/1564508555/]
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

[http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0485/test-artifacts/1564508555/integrationtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0485.tgz]
{noformat}
Started @ 2019-07-30 17:03:30.102 +
2019-07-30 17:04:45.273 + 
org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest 
test000PartitionedRegionCreate
Ended @ 2019-07-30 17:17:21.483 +{noformat}
The main thread is waiting for the TestWorker:
{noformat}
"main" #1 prio=5 os_prio=0 cpu=811.89ms elapsed=1307.75s tid=0x7f9504016800 
nid=0x6 waiting on condition  [0x7f950c837000]
   java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.3/Native Method)
- parking to wait for  <0xd0593fb0> (a 
java.util.concurrent.CountDownLatch$Sync)
at 
java.util.concurrent.locks.LockSupport.park(java.base@11.0.3/LockSupport.java:194)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.3/AbstractQueuedSynchronizer.java:885)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.3/AbstractQueuedSynchronizer.java:1039)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.3/AbstractQueuedSynchronizer.java:1345)
at 
java.util.concurrent.CountDownLatch.await(java.base@11.0.3/CountDownLatch.java:232)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:72)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:46)
at 
org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:93)
at 
org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:36)
at 
org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:125)
at 
org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:68)
at 
worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:62)
at 
worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:67)

   Locked ownable synchronizers:
- None
{noformat}
The TestWorker is waiting for multiple Partitioned Regions to be created, and 
is waiting on a re-lock:
{noformat}
"Test worker" #27 prio=5 os_prio=0 cpu=3783.27ms elapsed=1306.60s 
tid=0x7f9504afe800 nid=0x1b in Object.wait()  [0x7f94b72ca000]
   java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(java.base@11.0.3/Native Method)
- waiting on <0xd0863738> (a java.lang.Object)
at java.lang.Object.wait(java.base@11.0.3/Object.java:328)
at 
org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest.createMultiplePartitionedRegions(PartitionedRegionCreationJUnitTest.java:402)
- waiting to re-lock in wait() <0xd0863738> (a java.lang.Object)
at 
org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest.test000PartitionedRegionCreate(PartitionedRegionCreationJUnitTest.java:109)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.3/Native 
Method)
at 
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.3/NativeMethodAccessorImpl.java:62)
at 
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base@11.0.3/DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(java.base@11.0.3/Method.java:566)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 

[jira] [Created] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows

2019-07-30 Thread Donal Evans (JIRA)
Donal Evans created GEODE-7026:
--

 Summary: LocatorLauncherRemoteFileIntegrationTest > 
startDeletesStaleControlFiles fails on Windows
 Key: GEODE-7026
 URL: https://issues.apache.org/jira/browse/GEODE-7026
 Project: Geode
  Issue Type: Bug
  Components: tests
Reporter: Donal Evans


org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > 
startDeletesStaleControlFiles FAILED
[ 
|https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681]
 org.awaitility.core.ConditionTimeoutException: Assertion condition defined as 
a lambda expression in 
org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase 
expected:<[online]> but was:<[not responding]> within 300 seconds.
[ 
|https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682]
 
[ 
|https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683]
 Caused by:
[ 
|https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684]
 org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]>
 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Commented] (GEODE-6601) CI Failure: Timeout in LuceneIndexDestroyDUnitTest verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)

2019-07-30 Thread Donal Evans (JIRA)


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

Donal Evans commented on GEODE-6601:


Another occurrence manifesting as OOM: 
[http://hydradb.gemfire.pivotal.io/hdb/testresult/6051174]

> CI Failure: Timeout in LuceneIndexDestroyDUnitTest 
> verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK)
> 
>
> Key: GEODE-6601
> URL: https://issues.apache.org/jira/browse/GEODE-6601
> Project: Geode
>  Issue Type: Bug
>Reporter: Helena Bales
>Assignee: xiaojian zhou
>Priority: Major
>
> DistributedTestJDK11 failed due to timeout with a hang in 
> org.apache.geode.cache.lucene.LuceneIndexDestroyDUnitTest 
> verifyDestroyAllIndexesWhileDoingPuts(PARTITION_OVERFLOW_TO_DISK).
> CI Failure here: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/579
> Test results here: 
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-results/distributedTest/1554409876/
> Test artifacts here: 
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.10.0-SNAPSHOT.0137/test-artifacts/1554409876/distributedtestfiles-OpenJDK11-1.10.0-SNAPSHOT.0137.tgz



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows

2019-07-30 Thread Donal Evans (JIRA)


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

Donal Evans updated GEODE-7026:
---
Labels: IntegrationTest Windows  (was: integration-tests windows)

> LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles 
> fails on Windows
> -
>
> Key: GEODE-7026
> URL: https://issues.apache.org/jira/browse/GEODE-7026
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Donal Evans
>Priority: Major
>  Labels: IntegrationTest, Windows
>
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > 
> startDeletesStaleControlFiles FAILED
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681]
>  org.awaitility.core.ConditionTimeoutException: Assertion condition defined 
> as a lambda expression in 
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase 
> expected:<[online]> but was:<[not responding]> within 300 seconds.
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682]
>  
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683]
>  Caused by:
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684]
>  org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]>
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Updated] (GEODE-7026) LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles fails on Windows

2019-07-30 Thread Donal Evans (JIRA)


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

Donal Evans updated GEODE-7026:
---
Labels: integration-tests windows  (was: )

> LocatorLauncherRemoteFileIntegrationTest > startDeletesStaleControlFiles 
> fails on Windows
> -
>
> Key: GEODE-7026
> URL: https://issues.apache.org/jira/browse/GEODE-7026
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Donal Evans
>Priority: Major
>  Labels: integration-tests, windows
>
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest > 
> startDeletesStaleControlFiles FAILED
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1681]
>  org.awaitility.core.ConditionTimeoutException: Assertion condition defined 
> as a lambda expression in 
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase 
> expected:<[online]> but was:<[not responding]> within 300 seconds.
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1682]
>  
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1683]
>  Caused by:
> [ 
> |https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/159#L5d3266c7:1684]
>  org.junit.ComparisonFailure: expected:<[online]> but was:<[not responding]>
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)


[jira] [Assigned] (GEODE-7034) need to refactor the PeerTypeRegistration to be junit testable

2019-10-02 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7034:
--

Assignee: Donal Evans

> need to refactor the PeerTypeRegistration to be junit testable
> --
>
> Key: GEODE-7034
> URL: https://issues.apache.org/jira/browse/GEODE-7034
> Project: Geode
>  Issue Type: Bug
>Reporter: Xiaojian Zhou
>Assignee: Donal Evans
>Priority: Major
>
> The PeerTypeRegistration has no junit test. We are using dunit test and 
> integration test to cover the code. 
> According to Darrel's suggestion, we should refactor it to be junit testable 
> and add junit tests for each components. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7405) Documentation for describe query-service command

2019-11-04 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7405:
---
Labels: GeodeCommons  (was: )

> Documentation for describe query-service command
> 
>
> Key: GEODE-7405
> URL: https://issues.apache.org/jira/browse/GEODE-7405
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7405) Documentation for describe query-service command

2019-11-04 Thread Donal Evans (Jira)
Donal Evans created GEODE-7405:
--

 Summary: Documentation for describe query-service command
 Key: GEODE-7405
 URL: https://issues.apache.org/jira/browse/GEODE-7405
 Project: Geode
  Issue Type: New Feature
  Components: docs
Reporter: Donal Evans






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-6993) Documentation for alter query-service command

2019-11-11 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-6993:
--

Assignee: Donal Evans

> Documentation for alter query-service command
> -
>
> Key: GEODE-6993
> URL: https://issues.apache.org/jira/browse/GEODE-6993
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes

2019-10-31 Thread Donal Evans (Jira)
Donal Evans created GEODE-7396:
--

 Summary: JavaBeanAccessorMethodAuthorizer does not authorize 
methods on java.io classes
 Key: GEODE-7396
 URL: https://issues.apache.org/jira/browse/GEODE-7396
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


The following test failed using an authorizer with java.lang and java.io 
packages specified as allowed. It's unclear at this time if the problem is 
related specifically to the java.io package or if it is a problem with how the 
JavaBeanAccessorMethodAuthorizer handles multiple parameters.

 {noformat} 
@Test
  public void test() throws NoSuchMethodException {
Method disallowedJavaIOMethod = File.class.getMethod("getPath");

assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
 new File(""))).isTrue();
  } 
{noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes

2019-10-31 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7396:
--

Assignee: Donal Evans

> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> The following test failed using an authorizer with java.lang and java.io 
> packages specified as allowed. It's unclear at this time if the problem is 
> related specifically to the java.io package or if it is a problem with how 
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
>  {noformat} 
> @Test
>   public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
> 
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
>  new File(""))).isTrue();
>   } 
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes

2019-10-31 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7396:
---
Labels: GeodeCommons  (was: )

> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> The following test failed using an authorizer with java.lang and java.io 
> packages specified as allowed. It's unclear at this time if the problem is 
> related specifically to the java.io package or if it is a problem with how 
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
>  {noformat} 
> @Test
>   public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
> 
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
>  new File(""))).isTrue();
>   } 
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes

2019-10-31 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7396:
---
Component/s: security
 querying

> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
>  Issue Type: Bug
>  Components: querying, security
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The following test failed using an authorizer with java.lang and java.io 
> packages specified as allowed. It's unclear at this time if the problem is 
> related specifically to the java.io package or if it is a problem with how 
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
>  {noformat} 
> @Test
>   public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
> 
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
>  new File(""))).isTrue();
>   } 
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-6990) Implement Configuration Options for Method Authorizer

2019-11-13 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-6990.

Fix Version/s: 1.12.0
   Resolution: Implemented

> Implement Configuration Options for Method Authorizer
> -
>
> Key: GEODE-6990
> URL: https://issues.apache.org/jira/browse/GEODE-6990
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>  Time Spent: 11h 10m
>  Remaining Estimate: 0h
>
> Create a new {{QueryServiceConfig}} element at the {{CacheConfig}} level to 
> contain any configuration related to the query service, including the custom 
> {{MethodInvocationAuthorizer}}.
>  The resulting XML element should be as follows:
> {noformat}
> 
>  
>MyClass
>
>  stringValue
>
>  
> 
> {noformat}
> Instead of modifying the core {{cache-1.0.xsd}}, add another independent 
> {{xsd}} file as an extension of the cache’s configuration. An example of how 
> to do this can be seen in 
> [{{jdbc-1.0.xsd}}|https://github.com/apache/geode/blob/rel/v1.9.0/geode-connectors/src/main/resources/META-INF/schemas/geode.apache.org/schema/jdbc/jdbc-1.0.xsd].
>  This new configuration element and its properties should be stored and 
> retrieved through the cluster configuration service. For more details 
> regarding the interactions with the cluster configuration service see [For 
> extension developers: How to Add Elements Managed by Cluster Configuration 
> Service|https://cwiki.apache.org/confluence/display/GEODE/For+extension+developers%3A+How+to+Add+Elements+Managed+by+Cluster+Configuration+Service].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-6995) Use the Correct MethodInvocationAuthorizer

2019-11-13 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-6995.

Fix Version/s: 1.12.0
   Resolution: Resolved

Resolved as part of GEODE-6990

> Use the Correct MethodInvocationAuthorizer
> --
>
> Key: GEODE-6995
> URL: https://issues.apache.org/jira/browse/GEODE-6995
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, querying
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>
> Modify the {{DefaultQueryService}} class to 
> [instantiate|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L117-L131]
>  the required {{MethodInvocationAuthorizer}} obtained from the cluster 
> configuration service, none {{MethodInvocationAuthorizer}} at all, or the 
> default {{RestrictedMethodAuthorizer}}, depending on the options configured 
> by the user.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7460) DistributedMemberDUnitTest > testGroupsInAllVMs Failure

2019-11-18 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7460:


Occurred again on 11/18/19:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0023/test-results/distributedTest/1573869296/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0023/test-artifacts/1573869296/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0023.tgz

> DistributedMemberDUnitTest > testGroupsInAllVMs Failure
> ---
>
> Key: GEODE-7460
> URL: https://issues.apache.org/jira/browse/GEODE-7460
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: Robert Houghton
>Priority: Major
>
> From the failing job:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-results/distributedTest/1573784422/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0016/test-artifacts/1573784422/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0016.tgz
> DistributedTest failure due to exception:
> org.apache.geode.distributed.DistributedMemberDUnitTest > testGroupsInAllVMs 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run in VM 0 running 
> on Host 3e09f1029b44 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at 
> org.apache.geode.distributed.DistributedMemberDUnitTest.testGroupsInAllVMs(DistributedMemberDUnitTest.java:333)
> Caused by:
> org.apache.geode.SystemConnectException: One or more peers generated 
> exceptions during connection attempt
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1625)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:354)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:759)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:136)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3009)
> at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:269)
> at 
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:159)
> at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.getSystem(JUnit4DistributedTestCase.java:181)
> at 
> org.apache.geode.distributed.DistributedMemberDUnitTest$6.run(DistributedMemberDUnitTest.java:339)
> Caused by:
> 
> org.apache.geode.distributed.DistributedSystemDisconnectedException: 
> DistributedSystem is shutting down, caused by 
> org.apache.geode.ForcedDisconnectException: Exiting due to possible network 
> partition event due to loss of 1 cache processes: 
> [172.17.0.14(myName:1):41001]
> at 
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1591)
> at 
> org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.send(GMSMembershipManager.java:1751)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2058)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1985)
> at 
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:74)
> at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1622)
> ... 8 more
> Caused by:
> org.apache.geode.ForcedDisconnectException: Exiting due to 
> possible network partition event due to loss of 1 cache processes: 
> [172.17.0.14(myName:1):41001]
> 

[jira] [Commented] (GEODE-6107) CI Failure: org.apache.geode.management.JMXMBeanReconnectDUnitTest > testRemoteBeanKnowledge_MaintainServerAndCrashLocator

2019-11-18 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-6107:


Another failure:

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1292

> CI Failure: org.apache.geode.management.JMXMBeanReconnectDUnitTest > 
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator
> --
>
> Key: GEODE-6107
> URL: https://issues.apache.org/jira/browse/GEODE-6107
> Project: Geode
>  Issue Type: Bug
>Reporter: Ryan McMahon
>Assignee: Helena Bales
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.9.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Build:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/172
> Results:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.210/test-results/distributedTest/1543449109/
> Artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.210/test-artifacts/1543449109/distributedtestfiles-OpenJDK8-1.9.0-build.210.tgz
> {noformat}org.apache.geode.management.JMXMBeanReconnectDUnitTest > 
> testRemoteBeanKnowledge_MaintainServerAndCrashLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with alias 
> 'Locators must agree on the state of the system' didn't complete within 300 
> seconds because assertion condition defined as a lambda expression in 
> org.apache.geode.management.JMXMBeanReconnectDUnitTest 
> Expecting:
>   <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
> GemFire:service=FileUploader,type=Distributed,
> GemFire:service=System,type=Distributed,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one,
> 
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one,
> GemFire:service=Locator,type=Member,member=locator-one,
> GemFire:type=Member,member=locator-one,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-two,
> 
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-two,
> GemFire:service=Locator,type=Member,member=locator-two,
> GemFire:type=Member,member=locator-two,
> 
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> GemFire:service=CacheServer,port=33929,type=Member,member=server-2,
> GemFire:type=Member,member=server-2,
> 
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> GemFire:service=CacheServer,port=46497,type=Member,member=server-3,
> GemFire:type=Member,member=server-3]>
> to contain exactly (and in same order):
>   <[GemFire:service=Region,name="/test-region-1",type=Distributed,
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed,
> GemFire:service=AccessControl,type=Distributed,
> GemFire:service=FileUploader,type=Distributed,
> GemFire:service=System,type=Distributed,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one,
> GemFire:service=Locator,type=Member,member=locator-one,
> GemFire:type=Member,member=locator-one,
> 
> GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-two,
> 
> GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-two,
> GemFire:service=Locator,type=Member,member=locator-two,
> GemFire:type=Member,member=locator-two,
> 
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-2,
> GemFire:service=CacheServer,port=33929,type=Member,member=server-2,
> GemFire:type=Member,member=server-2,
> 
> GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
> GemFire:service=CacheServer,port=46497,type=Member,member=server-3,
> GemFire:type=Member,member=server-3]>
> but some elements were not expected:
>   
> <[GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one]>
> .
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> 

[jira] [Assigned] (GEODE-6995) Use the Correct MethodInvocationAuthorizer

2019-11-11 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-6995:
--

Assignee: Donal Evans

> Use the Correct MethodInvocationAuthorizer
> --
>
> Key: GEODE-6995
> URL: https://issues.apache.org/jira/browse/GEODE-6995
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration, querying
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> Modify the {{DefaultQueryService}} class to 
> [instantiate|https://github.com/apache/geode/blob/rel/v1.9.0/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L117-L131]
>  the required {{MethodInvocationAuthorizer}} obtained from the cluster 
> configuration service, none {{MethodInvocationAuthorizer}} at all, or the 
> default {{RestrictedMethodAuthorizer}}, depending on the options configured 
> by the user.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7467) DistributedTest fails with suspicious string "java.lang.ClassNotFoundException: does.not.Exist"

2019-11-18 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7467:
--

Assignee: Kirk Lund

> DistributedTest fails with suspicious string 
> "java.lang.ClassNotFoundException: does.not.Exist"
> ---
>
> Key: GEODE-7467
> URL: https://issues.apache.org/jira/browse/GEODE-7467
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Kirk Lund
>Priority: Major
>
> org.apache.geode.test.greplogs.LogConsumerDistributedTest > 
> errorLevel_exceptionMessage_loggedInBefore_failsInLocator FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3
> [error 2019/11/18 11:42:50.004 GMT  
> tid=32] java.lang.ClassNotFoundException: does.not.Exist
> 238 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0025/test-results/distributedTest/1574084287/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0025/test-artifacts/1574084287/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0025.tgz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7467) DistributedTest fails with suspicious string "java.lang.ClassNotFoundException: does.not.Exist"

2019-11-18 Thread Donal Evans (Jira)
Donal Evans created GEODE-7467:
--

 Summary: DistributedTest fails with suspicious string 
"java.lang.ClassNotFoundException: does.not.Exist"
 Key: GEODE-7467
 URL: https://issues.apache.org/jira/browse/GEODE-7467
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


org.apache.geode.test.greplogs.LogConsumerDistributedTest > 
errorLevel_exceptionMessage_loggedInBefore_failsInLocator FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 3

[error 2019/11/18 11:42:50.004 GMT  
tid=32] java.lang.ClassNotFoundException: does.not.Exist

238 tests completed, 1 failed

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0025/test-results/distributedTest/1574084287/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

http://files.apachegeode-ci.info/builds/apache-develop-main/1.12.0-SNAPSHOT.0025/test-artifacts/1574084287/distributedtestfiles-OpenJDK8-1.12.0-SNAPSHOT.0025.tgz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-6991) Create AlterQueryService GFSH Command

2019-11-21 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-6991.

Fix Version/s: 1.12.0
   Resolution: Implemented

> Create AlterQueryService GFSH Command
> -
>
> Key: GEODE-6991
> URL: https://issues.apache.org/jira/browse/GEODE-6991
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> *As a* Geode user
>  *I want to* configure several aspects of the query service
>  *so that I can* change the method invocation authorizer.
> The _Method Invocation Authorizer_ should be configurable / exchangeable in 
> runtime (it doesn’t need to be an instantaneous update, eventual consistency 
> is tolerable) and *there can only be one authorizer configured per cluster:* 
> {{alter query-service 
> --method-authorizer=test.Authorizer\{'param':'value'\}}}.
>  Add Unit, Integration and Distributed tests for the new command.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-6993) Documentation for alter query-service command

2019-11-21 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-6993.

Fix Version/s: 1.12.0
   Resolution: Done

> Documentation for alter query-service command
> -
>
> Key: GEODE-6993
> URL: https://issues.apache.org/jira/browse/GEODE-6993
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7405) Documentation for describe query-service command

2019-11-21 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7405:
--

Assignee: Donal Evans

> Documentation for describe query-service command
> 
>
> Key: GEODE-7405
> URL: https://issues.apache.org/jira/browse/GEODE-7405
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7510) Records are being deleted during Redundancy GII and records that should have been deleted are being left on redundant host.

2019-12-10 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7510:


Reoccurred on this CI run: 
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1367#L5de89f11:708]

> Records are being deleted during Redundancy GII and records that should have 
> been deleted are being left on redundant host.
> ---
>
> Key: GEODE-7510
> URL: https://issues.apache.org/jira/browse/GEODE-7510
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: Juan Ramos
>Assignee: Mark Hanson
>Priority: Major
>  Labels: redundancy
>
> PartitionedRegionSizeDUnitTest.testBug39868 is showing a product issue where 
> deletions are happening during GII and things are left out of sync. This is 
> reproducible by running this test repeatedly on your local machine.
>  
> I've came across this one during the [CI 
> run|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/DistributedTestOpenJDK11/builds/5194]
>  for one of my {{Pull Request}}:
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest > testBug39868 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest$$Lambda$47/883874659.run
>  in VM 1 running on Host localhost with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest.testBug39868(PartitionedRegionSizeDUnitTest.java:126)
> Caused by:
> org.junit.ComparisonFailure: expected:<[0]L> but was:<[672]L>
> 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.cache.PartitionedRegionSizeDUnitTest.lambda$testBug39868$bb17a952$5(PartitionedRegionSizeDUnitTest.java:129)
> {noformat}
> Below are the results from running the test 200 times locally with the latest 
> {{develop}} branch:
> {noformat}
> $ geode (develop)> git log -n 3 --oneline
> 6933232574 (HEAD -> develop, origin/develop, origin/HEAD) GEODE-7487: Update 
> Running CQ Context (#4369)
> 94ec51b35e GEODE-7496 - Decouple management API from Gfsh RebalanceCommand 
> (#4370)
> 3b85e5cb88 GEODE-7436: Deploy jar using semantic versioning scheme  (#4382)
> $ geode (develop)> ./gradlew repeatDistributedTest --no-parallel -Prepeat=200 
> -PfailOnNoMatchingTests=false --tests 
> PartitionedRegionSizeDUnitTest.testBug39868
> > Task :geode-core:repeatDistributedTest
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest > testBug39868 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest$$Lambda$31/214451470.run
>  in VM 1 running on Host localhost with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest.testBug39868(PartitionedRegionSizeDUnitTest.java:126)
> Caused by:
> org.junit.ComparisonFailure: expected:<[]0L> but was:<[56]0L>
> 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.cache.PartitionedRegionSizeDUnitTest.lambda$testBug39868$bb17a952$5(PartitionedRegionSizeDUnitTest.java:129)
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest > testBug39868 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest$$Lambda$31/214451470.run
>  in VM 1 running on Host localhost with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.internal.cache.PartitionedRegionSizeDUnitTest.testBug39868(PartitionedRegionSizeDUnitTest.java:126)
> Caused by:
> org.junit.ComparisonFailure: 

[jira] [Created] (GEODE-7566) CI Failure: WindowsUnitTestOpenJDK11 fails to create instance

2019-12-10 Thread Donal Evans (Jira)
Donal Evans created GEODE-7566:
--

 Summary: CI Failure: WindowsUnitTestOpenJDK11 fails to create 
instance
 Key: GEODE-7566
 URL: https://issues.apache.org/jira/browse/GEODE-7566
 Project: Geode
  Issue Type: Bug
  Components: ci
Reporter: Donal Evans


Failure occurred on [this 
run|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/1128]:

{noformat}
/tmp/build/5ca5b479/geode /tmp/build/5ca5b479
 /tmp/build/5ca5b479
 Hashed apache-develop-main-WindowsUnitTestOpenJDK11-build8-test11-job#1128 (67 
chars) -> heavy-lifter-69c13f20-adb2-59b2-bb6c-864e6f4be6ba (49 chars)
 cat: can't open 'new/prior-zone': No such file or directory
{noformat}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7566) CI Failure: WindowsUnitTestOpenJDK11 fails to create instance

2019-12-10 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7566:
--

Assignee: Scott Jewell

> CI Failure: WindowsUnitTestOpenJDK11 fails to create instance
> -
>
> Key: GEODE-7566
> URL: https://issues.apache.org/jira/browse/GEODE-7566
> Project: Geode
>  Issue Type: Bug
>  Components: ci
>Reporter: Donal Evans
>Assignee: Scott Jewell
>Priority: Major
>
> Failure occurred on [this 
> run|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK11/builds/1128]:
> {noformat}
> /tmp/build/5ca5b479/geode /tmp/build/5ca5b479
>  /tmp/build/5ca5b479
>  Hashed apache-develop-main-WindowsUnitTestOpenJDK11-build8-test11-job#1128 
> (67 chars) -> heavy-lifter-69c13f20-adb2-59b2-bb6c-864e6f4be6ba (49 chars)
>  cat: can't open 'new/prior-zone': No such file or directory
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7337) Create DescribeQueryService GFSH Command

2019-10-23 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7337:
---
Labels: GeodeCommons  (was: )

> Create DescribeQueryService GFSH Command
> 
>
> Key: GEODE-7337
> URL: https://issues.apache.org/jira/browse/GEODE-7337
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> To complement the addition of the AlterQueryService GFSH command, a command 
> to describe the QueryConfigurationService should be added.
> The description should include the fully qualified class name of the 
> {{MethodInvocationAuthorizer}} currently in use along with any parameters 
> used to create it if applicable. The description should also return the value 
> of the {{gemfireQueryService.allowUntrustedMethodInvocation}} system property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7337) Create DescribeQueryService GFSH Command

2019-10-23 Thread Donal Evans (Jira)
Donal Evans created GEODE-7337:
--

 Summary: Create DescribeQueryService GFSH Command
 Key: GEODE-7337
 URL: https://issues.apache.org/jira/browse/GEODE-7337
 Project: Geode
  Issue Type: New Feature
  Components: gfsh
Reporter: Donal Evans


To complement the addition of the AlterQueryService GFSH command, a command to 
describe the QueryConfigurationService should be added.

The description should include the fully qualified class name of the 
{{MethodInvocationAuthorizer}} currently in use along with any parameters used 
to create it if applicable. The description should also return the value of the 
{{gemfireQueryService.allowUntrustedMethodInvocation}} system property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7337) Create DescribeQueryService GFSH Command

2019-10-23 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7337:
--

Assignee: Donal Evans

> Create DescribeQueryService GFSH Command
> 
>
> Key: GEODE-7337
> URL: https://issues.apache.org/jira/browse/GEODE-7337
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> To complement the addition of the AlterQueryService GFSH command, a command 
> to describe the QueryConfigurationService should be added.
> The description should include the fully qualified class name of the 
> {{MethodInvocationAuthorizer}} currently in use along with any parameters 
> used to create it if applicable. The description should also return the value 
> of the {{gemfireQueryService.allowUntrustedMethodInvocation}} system property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-6991) Create AlterQueryService GFSH Command

2019-10-23 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-6991:
--

Assignee: Donal Evans

> Create AlterQueryService GFSH Command
> -
>
> Key: GEODE-6991
> URL: https://issues.apache.org/jira/browse/GEODE-6991
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> *As a* Geode user
>  *I want to* configure several aspects of the query service
>  *so that I can* change the method invocation authorizer.
> The _Method Invocation Authorizer_ should be configurable / exchangeable in 
> runtime (it doesn’t need to be an instantaneous update, eventual consistency 
> is tolerable) and *there can only be one authorizer configured per cluster:* 
> {{alter query-service 
> --method-authorizer=test.Authorizer\{'param':'value'\}}}.
>  Add Unit, Integration and Distributed tests for the new command.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7279) Warning message for deprecated allowUntrustedMethodInvocation should be only logged once

2019-10-18 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7279.

Fix Version/s: 1.11.0
   Resolution: Fixed

> Warning message for deprecated allowUntrustedMethodInvocation should be only 
> logged once
> 
>
> Key: GEODE-7279
> URL: https://issues.apache.org/jira/browse/GEODE-7279
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Minor
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> The warning message is still shown every single time the user invokes 
> {{getQueryService()}}, and that's basically because the 
> {{deprecatedWarningHasBeenShown}} attribute within {{DefaultQueryService}} is 
> an instance variable instead of a static one.
> As an example, after running the following test:
> {code}
> public class DefaultQueryServiceIntegrationTest {
>   static {
> System.setProperty(GEMFIRE_PREFIX + 
> "QueryService.allowUntrustedMethodInvocation", "true");
>   }
>   @Rule
>   public TestName testName = new TestName();
>   @Rule
>   public ServerStarterRule server = new ServerStarterRule().withAutoStart();
>   public void terst() throws Exception {
> server.getCache().getQueryService();
> server.getCache().getQueryService();
>   }
> }
> {code}
> The logs contain the warning message 3 times:
> {noformat}
> [warn 2019/10/08 17:25:39.378 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> [warn 2019/10/08 17:25:39.382 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> [warn 2019/10/08 17:25:39.382 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7360) CqSecurityExecutionContextTamperingDistributedTest > executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations is flaky

2019-10-25 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7360:
--

Assignee: Juan Ramos

> CqSecurityExecutionContextTamperingDistributedTest > 
> executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations is 
> flaky
> 
>
> Key: GEODE-7360
> URL: https://issues.apache.org/jira/browse/GEODE-7360
> Project: Geode
>  Issue Type: Bug
>  Components: cq, querying, security
>Reporter: Donal Evans
>Assignee: Juan Ramos
>Priority: Major
>
> The test fails intermittently with:
> org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest
>  > 
> executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations[RegionType:REPLICATE,
>  Accessor:name] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest$$Lambda$32/1087176052.run
>  in VM 2 running on Host 08f781443fd7 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at 
> org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest.executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations(CqSecurityExecutionContextTamperingDistributedTest.java:130)
> Caused by:
> org.junit.ComparisonFailure: expected:<[1]> but was:<[0]>
> 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.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest.lambda$executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations$bb17a952$2(CqSecurityExecutionContextTamperingDistributedTest.java:134)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7360) CqSecurityExecutionContextTamperingDistributedTest > executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations is flaky

2019-10-25 Thread Donal Evans (Jira)
Donal Evans created GEODE-7360:
--

 Summary: CqSecurityExecutionContextTamperingDistributedTest > 
executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations is flaky
 Key: GEODE-7360
 URL: https://issues.apache.org/jira/browse/GEODE-7360
 Project: Geode
  Issue Type: Bug
  Components: cq, querying, security
Reporter: Donal Evans


The test fails intermittently with:

org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest
 > 
executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations[RegionType:REPLICATE,
 Accessor:name] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest$$Lambda$32/1087176052.run
 in VM 2 running on Host 08f781443fd7 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
at 
org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
at 
org.apache.geode.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest.executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations(CqSecurityExecutionContextTamperingDistributedTest.java:130)

Caused by:
org.junit.ComparisonFailure: expected:<[1]> but was:<[0]>
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.cache.query.cq.internal.CqSecurityExecutionContextTamperingDistributedTest.lambda$executionContextShouldNotBeModifiableForCqQueriesWithMethodInvocations$bb17a952$2(CqSecurityExecutionContextTamperingDistributedTest.java:134)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-6462) [CI Failure] LocatorConnectionDUnitTest > testGetAvailableServersWithStats failed on validateStats

2019-10-25 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-6462:


Reproduced in 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1232.

Artifacts: 
http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0262/test-artifacts/1572008551/distributedtestfiles-OpenJDK8-1.11.0-SNAPSHOT.0262.tgz

> [CI Failure] LocatorConnectionDUnitTest > testGetAvailableServersWithStats 
> failed on validateStats
> --
>
> Key: GEODE-6462
> URL: https://issues.apache.org/jira/browse/GEODE-6462
> Project: Geode
>  Issue Type: Test
>  Components: core
>Reporter: Jens Deppe
>Priority: Major
>  Labels: ci
>
> This seems like a flakey test.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/443]
> The test and the protobuf code has not been updated in a while. This is 
> probably a flake.
> The following is the error thread
> {code:java}
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest
>  > testGetAvailableServersWithStats FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest$$Lambda$37/842046356.run
>  in VM 0 running on Host 22c25e73171b with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at 
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:85)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.validateStats(LocatorConnectionDUnitTest.java:234)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.testSocketWithStats(LocatorConnectionDUnitTest.java:127)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.testGetAvailableServersWithStats(LocatorConnectionDUnitTest.java:106)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest
>  that uses long, longlong, longlong, longlong, longint, intint expected:<3> 
> but was:<4> within 300 seconds.
> at 
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:145)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:122)
> at 
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at 
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:902)
> at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.lambda$validateStats$c7642ca0$1(LocatorConnectionDUnitTest.java:235)
> Caused by:
> java.lang.AssertionError: expected:<3> but was:<4>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at 
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.LocatorConnectionDUnitTest.lambda$null$0(LocatorConnectionDUnitTest.java:238)
> {code}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0487/test-results/distributedTest/1551228892/]
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-SNAPSHOT.0487/test-artifacts/1551228892/distributedtestfiles-OpenJDK8-1.9.0-SNAPSHOT.0487.tgz]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7337) Create DescribeQueryService GFSH Command

2019-11-26 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7337.

Fix Version/s: 1.12.0
   Resolution: Implemented

> Create DescribeQueryService GFSH Command
> 
>
> Key: GEODE-7337
> URL: https://issues.apache.org/jira/browse/GEODE-7337
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> To complement the addition of the AlterQueryService GFSH command, a command 
> to describe the QueryConfigurationService should be added.
> The description should include the fully qualified class name of the 
> {{MethodInvocationAuthorizer}} currently in use along with any parameters 
> used to create it if applicable. The description should also return the value 
> of the {{gemfireQueryService.allowUntrustedMethodInvocation}} system property.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7405) Documentation for describe query-service command

2019-11-27 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7405.

Fix Version/s: 1.12.0
   Resolution: Done

> Documentation for describe query-service command
> 
>
> Key: GEODE-7405
> URL: https://issues.apache.org/jira/browse/GEODE-7405
> Project: Geode
>  Issue Type: New Feature
>  Components: docs
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.12.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7521) Region name in RebalanceCommand is missing leading '/'

2019-12-02 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7521:
--

Assignee: Patrick Johnson

> Region name in RebalanceCommand is missing leading '/'
> --
>
> Key: GEODE-7521
> URL: https://issues.apache.org/jira/browse/GEODE-7521
> Project: Geode
>  Issue Type: Bug
>Reporter: Patrick Johnsn
>Assignee: Patrick Johnson
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7396) JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes

2019-11-01 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7396.

Fix Version/s: 1.11.0
   Resolution: Fixed

> JavaBeanAccessorMethodAuthorizer does not authorize methods on java.io classes
> --
>
> Key: GEODE-7396
> URL: https://issues.apache.org/jira/browse/GEODE-7396
> Project: Geode
>  Issue Type: Bug
>  Components: querying, security
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> The following test failed using an authorizer with java.lang and java.io 
> packages specified as allowed. It's unclear at this time if the problem is 
> related specifically to the java.io package or if it is a problem with how 
> the JavaBeanAccessorMethodAuthorizer handles multiple parameters.
>  {noformat} 
> @Test
>   public void test() throws NoSuchMethodException {
> Method disallowedJavaIOMethod = File.class.getMethod("getPath");
> 
> assertThat(authorizerWithStringAndIOPackageSpecified.authorize(allowedJavaIOMethod,
>  new File(""))).isTrue();
>   } 
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions

2019-09-24 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7242:
---
Labels: GeodeCommons  (was: )

> Incorrect documentation for AVG and SUM aggregate functions
> ---
>
> Key: GEODE-7242
> URL: https://issues.apache.org/jira/browse/GEODE-7242
> Project: Geode
>  Issue Type: Bug
>  Components: docs, querying
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> The documentation for OQL Aggregate Functions states that AVG and SUM always 
> return either a Float or Double, but the actual return type can be any of 
> Integer, Long, Float or Double.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions

2019-09-24 Thread Donal Evans (Jira)
Donal Evans created GEODE-7242:
--

 Summary: Incorrect documentation for AVG and SUM aggregate 
functions
 Key: GEODE-7242
 URL: https://issues.apache.org/jira/browse/GEODE-7242
 Project: Geode
  Issue Type: Bug
  Components: docs, querying
Reporter: Donal Evans


The documentation for OQL Aggregate Functions states that AVG and SUM always 
return either a Float or Double, but the actual return type can be any of 
Integer, Long, Float or Double.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7242) Incorrect documentation for AVG and SUM aggregate functions

2019-09-24 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7242:
---
Parent: GEODE-6969
Issue Type: Sub-task  (was: Bug)

> Incorrect documentation for AVG and SUM aggregate functions
> ---
>
> Key: GEODE-7242
> URL: https://issues.apache.org/jira/browse/GEODE-7242
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, querying
>Reporter: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> The documentation for OQL Aggregate Functions states that AVG and SUM always 
> return either a Float or Double, but the actual return type can be any of 
> Integer, Long, Float or Double.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7279) Warning message for deprecated allowUntrustedMethodInvocation should be only logged once

2019-10-08 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7279:
--

Assignee: Donal Evans

> Warning message for deprecated allowUntrustedMethodInvocation should be only 
> logged once
> 
>
> Key: GEODE-7279
> URL: https://issues.apache.org/jira/browse/GEODE-7279
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Minor
>  Labels: GeodeCommons
>
> The warning message is still shown every single time the user invokes 
> {{getQueryService()}}, and that's basically because the 
> {{deprecatedWarningHasBeenShown}} attribute within {{DefaultQueryService}} is 
> an instance variable instead of a static one.
> As an example, after running the following test:
> {code}
> public class DefaultQueryServiceIntegrationTest {
>   static {
> System.setProperty(GEMFIRE_PREFIX + 
> "QueryService.allowUntrustedMethodInvocation", "true");
>   }
>   @Rule
>   public TestName testName = new TestName();
>   @Rule
>   public ServerStarterRule server = new ServerStarterRule().withAutoStart();
>   public void terst() throws Exception {
> server.getCache().getQueryService();
> server.getCache().getQueryService();
>   }
> }
> {code}
> The logs contain the warning message 3 times:
> {noformat}
> [warn 2019/10/08 17:25:39.378 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> [warn 2019/10/08 17:25:39.382 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> [warn 2019/10/08 17:25:39.382 IST  tid=0xb] The property 
> gemfire.QueryService.allowUntrustedMethodInvocation is deprecated. To provide 
> the same functionality, please use the UnrestrictedMethodAuthorizer 
> implementation of MethodInvocationAuthorizer
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-6990) Implement Configuration Options for Method Authorizer

2019-10-09 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-6990:
--

Assignee: Donal Evans

> Implement Configuration Options for Method Authorizer
> -
>
> Key: GEODE-6990
> URL: https://issues.apache.org/jira/browse/GEODE-6990
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> Create a new {{QueryServiceConfig}} element at the {{CacheConfig}} level to 
> contain any configuration related to the query service, including the custom 
> {{MethodInvocationAuthorizer}}.
>  The resulting XML element should be as follows:
> {noformat}
> 
>  
>MyClass
>
>  stringValue
>
>  
> 
> {noformat}
> Instead of modifying the core {{cache-1.0.xsd}}, add another independent 
> {{xsd}} file as an extension of the cache’s configuration. An example of how 
> to do this can be seen in 
> [{{jdbc-1.0.xsd}}|https://github.com/apache/geode/blob/rel/v1.9.0/geode-connectors/src/main/resources/META-INF/schemas/geode.apache.org/schema/jdbc/jdbc-1.0.xsd].
>  This new configuration element and its properties should be stored and 
> retrieved through the cluster configuration service. For more details 
> regarding the interactions with the cluster configuration service see [For 
> extension developers: How to Add Elements Managed by Cluster Configuration 
> Service|https://cwiki.apache.org/confluence/display/GEODE/For+extension+developers%3A+How+to+Add+Elements+Managed+by+Cluster+Configuration+Service].



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11

2020-02-25 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7817:
---
Description: 
Following the changes introduced in 
[https://github.com/apache/geode/pull/4629], hangs are frequently observed when 
starting more than one server configured with an async-distribution-timeout 
when running on JDK 11.

A test to reproduce the issue is provided below:
{code:java}
public class ConnectionChangeHangTest {
  int serversToStart = 3;

  @Rule
  public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart + 
1);

  @Test
  /*
   * This test must be run with JDK 11 for it to show the hang
   */
  public void test() {
MemberVM locator = cluster.startLocatorVM(0);
int locatorPort = locator.getPort();

for (int i = 0; i < serversToStart; ++i) {
  cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
  .withProperty("async-distribution-timeout", "5"));
}
  }
}
{code}

  was:Following the changes introduced in 
[https://github.com/apache/geode/pull/4629], hangs are frequently observed when 
starting more than one server configured with an async-distribution-timeout 
when running on JDK 11.


> Server creation hangs when async-distribution-timeout is set on JDK11
> -
>
> Key: GEODE-7817
> URL: https://issues.apache.org/jira/browse/GEODE-7817
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Priority: Major
>
> Following the changes introduced in 
> [https://github.com/apache/geode/pull/4629], hangs are frequently observed 
> when starting more than one server configured with an 
> async-distribution-timeout when running on JDK 11.
> A test to reproduce the issue is provided below:
> {code:java}
> public class ConnectionChangeHangTest {
>   int serversToStart = 3;
>   @Rule
>   public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart + 
> 1);
>   @Test
>   /*
>* This test must be run with JDK 11 for it to show the hang
>*/
>   public void test() {
> MemberVM locator = cluster.startLocatorVM(0);
> int locatorPort = locator.getPort();
> for (int i = 0; i < serversToStart; ++i) {
>   cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
>   .withProperty("async-distribution-timeout", "5"));
> }
>   }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11

2020-02-25 Thread Donal Evans (Jira)
Donal Evans created GEODE-7817:
--

 Summary: Server creation hangs when async-distribution-timeout is 
set on JDK11
 Key: GEODE-7817
 URL: https://issues.apache.org/jira/browse/GEODE-7817
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


Following the changes introduced in 
[https://github.com/apache/geode/pull/4629], hangs are frequently observed when 
starting more than one server configured with an async-distribution-timeout 
when running on JDK 11.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7643) Gateway unprocessedTokensMap appears to grow without bounds with replicated regions and peer accessors

2020-01-09 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7643:
---
Description: 
When peer accessors do puts to a replicated region with a serial gateway sender 
via multiple threads and on the same key, 
{{ConcurrentCacheModificationException}} in {{LocalRegion.virtualPut}} causes 
{{notifyGatewaySender}} to be called, which puts the event into the queue. 
Since the {{AbstractUpdateOperation.doPutOrCreate}} method can potentially call 
{{LocalRegion.virtualPut}} three times and encounter a 
{{ConcurrentCacheModificationException}} each time, this can lead to the event 
being put in the queue twice but only removed once and causing the 
unprocessedTokensMap to accumulate events.

Here are the two stacks:
{noformat}
[warn 2019/12/02 12:47:59.102 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
ConcurrentCacheModificationException about to notifyGatewaySender 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
 ifNew=false; ifOld=true; overwriteDestroyed=false; eventIdentity=329453507; 
eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
payloadLength=0 bytes]
java.lang.Exception
at 
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
at 
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at 
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:182)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
at 
org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:427)
{noformat}
{noformat}
[warn 2019/12/02 12:47:59.108 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
ConcurrentCacheModificationException about to notifyGatewaySender 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
 ifNew=false; ifOld=false; overwriteDestroyed=true; eventIdentity=329453507; 
eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
payloadLength=0 bytes]
java.lang.Exception
at 
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
at 
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at 
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:194)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
{noformat}
Here are the corresponding puts into the queue:
{noformat}
[warn 2019/12/02 12:47:59.104 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX SerialGatewaySenderQueue.putAndGetKey key=3625; 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=0x30002|5;sequenceID=273];
 eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; 
price=163.08897399902344; payloadLength=0 bytes]
{noformat}
{noformat}
[warn 2019/12/02 12:47:59.110 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX SerialGatewaySenderQueue.putAndGetKey key=3635; 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=0x30002|5;sequenceID=273];
 eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; 
price=163.08897399902344; payloadLength=0 bytes]
{noformat}
On the secondary, when the event is received 

[jira] [Resolved] (GEODE-7643) Gateway unprocessedTokensMap appears to grow without bounds with replicated regions and peer accessors

2020-01-09 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7643.

Fix Version/s: 1.12.0
   Resolution: Fixed

> Gateway unprocessedTokensMap appears to grow without bounds with replicated 
> regions and peer accessors
> --
>
> Key: GEODE-7643
> URL: https://issues.apache.org/jira/browse/GEODE-7643
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> When peer accessors do puts to a replicated region with a serial gateway 
> sender via multiple threads and on the same key, 
> {{ConcurrentCacheModificationException}} in {{LocalRegion.virtualPut}} causes 
> {{notifyGatewaySender}} to be called, which puts the event into the queue. 
> Since the {{AbstractUpdateOperation.doPutOrCreate}} method can potentially 
> call {{LocalRegion.virtualPut}} three times and encounter a 
> {{ConcurrentCacheModificationException}} each time, this can lead to the 
> event being put in the queue twice but only removed once and causing the 
> unprocessedTokensMap to accumulate events.
> Here are the two stacks:
> {noformat}
> [warn 2019/12/02 12:47:59.102 PST  10.255.202.119(gateway-ln-2:85182):41004 unshared ordered uid=11 dom #2 
> port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
> ConcurrentCacheModificationException about to notifyGatewaySender 
> eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
>  ifNew=false; ifOld=true; overwriteDestroyed=false; eventIdentity=329453507; 
> eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
> payloadLength=0 bytes]
> java.lang.Exception
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:182)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:427)
> {noformat}
> {noformat}
> [warn 2019/12/02 12:47:59.108 PST  10.255.202.119(gateway-ln-2:85182):41004 unshared ordered uid=11 dom #2 
> port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
> ConcurrentCacheModificationException about to notifyGatewaySender 
> eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
>  ifNew=false; ifOld=false; overwriteDestroyed=true; eventIdentity=329453507; 
> eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
> payloadLength=0 bytes]
> java.lang.Exception
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:194)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
> {noformat}
> Here are the 

[jira] [Created] (GEODE-7643) Gateway unprocessedTokensMap appears to grow without bounds with replicated regions and peer accessors

2020-01-02 Thread Donal Evans (Jira)
Donal Evans created GEODE-7643:
--

 Summary: Gateway unprocessedTokensMap appears to grow without 
bounds with replicated regions and peer accessors
 Key: GEODE-7643
 URL: https://issues.apache.org/jira/browse/GEODE-7643
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Donal Evans


When peer accessors do puts to a replicated region with a serial gateway sender 
via multiple threads and on the same key, 
{{ConcurrentCacheModificationException}} in {{LocalRegion.virtualPut}} causes 
{{notifyGatewaySender}} to be called, which puts the event into the queue, 
leading to the event being put in the queue twice but only removed once and 
causing the unprocessedTokensMap to accumulate events.

Here are the two stacks:
{noformat}

[warn 2019/12/02 12:47:59.102 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
ConcurrentCacheModificationException about to notifyGatewaySender 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
 ifNew=false; ifOld=true; overwriteDestroyed=false; eventIdentity=329453507; 
eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
payloadLength=0 bytes]
java.lang.Exception
at 
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
at 
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at 
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:182)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
at 
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
at 
org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:427)
{noformat}

{noformat}
[warn 2019/12/02 12:47:59.108 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
ConcurrentCacheModificationException about to notifyGatewaySender 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
 ifNew=false; ifOld=false; overwriteDestroyed=true; eventIdentity=329453507; 
eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
payloadLength=0 bytes]
java.lang.Exception
at 
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
at 
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
at 
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:194)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
at 
org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
at 
org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
{noformat}
Here are the corresponding puts into the queue:
{noformat}
[warn 2019/12/02 12:47:59.104 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX SerialGatewaySenderQueue.putAndGetKey key=3625; 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=0x30002|5;sequenceID=273];
 eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; 
price=163.08897399902344; payloadLength=0 bytes]
{noformat}
{noformat}
[warn 2019/12/02 12:47:59.110 PST :41004 unshared ordered uid=11 dom #2 
port=59034> tid=0x61] XXX SerialGatewaySenderQueue.putAndGetKey key=3635; 
eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=0x30002|5;sequenceID=273];
 eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; 
price=163.08897399902344; payloadLength=0 bytes]
{noformat}
On the secondary, when the event is 

[jira] [Assigned] (GEODE-7643) Gateway unprocessedTokensMap appears to grow without bounds with replicated regions and peer accessors

2020-01-02 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7643:
--

Assignee: Donal Evans

> Gateway unprocessedTokensMap appears to grow without bounds with replicated 
> regions and peer accessors
> --
>
> Key: GEODE-7643
> URL: https://issues.apache.org/jira/browse/GEODE-7643
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> When peer accessors do puts to a replicated region with a serial gateway 
> sender via multiple threads and on the same key, 
> {{ConcurrentCacheModificationException}} in {{LocalRegion.virtualPut}} causes 
> {{notifyGatewaySender}} to be called, which puts the event into the queue, 
> leading to the event being put in the queue twice but only removed once and 
> causing the unprocessedTokensMap to accumulate events.
> Here are the two stacks:
> {noformat}
> [warn 2019/12/02 12:47:59.102 PST  10.255.202.119(gateway-ln-2:85182):41004 unshared ordered uid=11 dom #2 
> port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
> ConcurrentCacheModificationException about to notifyGatewaySender 
> eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
>  ifNew=false; ifOld=true; overwriteDestroyed=false; eventIdentity=329453507; 
> eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
> payloadLength=0 bytes]
> java.lang.Exception
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:182)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
>   at 
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:427)
> {noformat}
> {noformat}
> [warn 2019/12/02 12:47:59.108 PST  10.255.202.119(gateway-ln-2:85182):41004 unshared ordered uid=11 dom #2 
> port=59034> tid=0x61] XXX LocalRegion.virtualPut caught 
> ConcurrentCacheModificationException about to notifyGatewaySender 
> eventId=EventID[10.255.202.119(accessor-ln-1):41005;threadID=5;sequenceID=273];
>  ifNew=false; ifOld=false; overwriteDestroyed=true; eventIdentity=329453507; 
> eventValue=Trade[id=-1501795011; cusip=PVTL; shares=29; price=163; 
> payloadLength=0 bytes]
> java.lang.Exception
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5591)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:385)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:162)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5561)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:194)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:287)
>   at 
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:258)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1206)
>   at 
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1108)
> {noformat}
> Here are the corresponding puts into the queue:
> {noformat}
> [warn 2019/12/02 12:47:59.104 PST  10.255.202.119(gateway-ln-2:85182):41004 unshared ordered uid=11 dom #2 
> port=59034> tid=0x61] XXX SerialGatewaySenderQueue.putAndGetKey key=3625; 
> 

[jira] [Resolved] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11

2020-03-14 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7817.

Fix Version/s: 1.13.0
 Assignee: Donal Evans
   Resolution: Fixed

Resolved by https://github.com/apache/geode/pull/4751

> Server creation hangs when async-distribution-timeout is set on JDK11
> -
>
> Key: GEODE-7817
> URL: https://issues.apache.org/jira/browse/GEODE-7817
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.13.0
>
>
> Following the changes introduced in 
> [https://github.com/apache/geode/pull/4629], hangs are frequently observed 
> when starting more than one server configured with an 
> async-distribution-timeout when running on JDK 11.
> A test to reproduce the issue is provided below:
> {code:java}
> public class ConnectionChangeHangTest {
>   int serversToStart = 3;
>   @Rule
>   public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart + 
> 1);
>   @Test
>   /*
>* This test must be run with JDK 11 for it to show the hang
>*/
>   public void test() {
> MemberVM locator = cluster.startLocatorVM(0);
> int locatorPort = locator.getPort();
> for (int i = 0; i < serversToStart; ++i) {
>   cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
>   .withProperty("async-distribution-timeout", "5"));
> }
>   }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7817) Server creation hangs when async-distribution-timeout is set on JDK11

2020-03-14 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7817:


Resolved by https://github.com/apache/geode/pull/4751

> Server creation hangs when async-distribution-timeout is set on JDK11
> -
>
> Key: GEODE-7817
> URL: https://issues.apache.org/jira/browse/GEODE-7817
> Project: Geode
>  Issue Type: Bug
>Reporter: Donal Evans
>Priority: Major
>
> Following the changes introduced in 
> [https://github.com/apache/geode/pull/4629], hangs are frequently observed 
> when starting more than one server configured with an 
> async-distribution-timeout when running on JDK 11.
> A test to reproduce the issue is provided below:
> {code:java}
> public class ConnectionChangeHangTest {
>   int serversToStart = 3;
>   @Rule
>   public ClusterStartupRule cluster = new ClusterStartupRule(serversToStart + 
> 1);
>   @Test
>   /*
>* This test must be run with JDK 11 for it to show the hang
>*/
>   public void test() {
> MemberVM locator = cluster.startLocatorVM(0);
> int locatorPort = locator.getPort();
> for (int i = 0; i < serversToStart; ++i) {
>   cluster.startServerVM(i + 1, s -> s.withConnectionToLocator(locatorPort)
>   .withProperty("async-distribution-timeout", "5"));
> }
>   }
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-08 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7954:
---
Description: 
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * Redundancy is fully satisfied for all regions that were included, either 
explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
At least one bucket in a region has fewer than the configured number of 
redundant copies.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--reassign-primaries}} argument to determine if 
primaries should be reassigned or not during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]

  was:
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{\-\-include-region}} and 
{{\-\-exclude-region}} arguments, similar to the existing rebalance command. If 
neither argument is specified, all regions will be included. Included regions 
will take precedence over excluded regions when both are specified. The restore 
redundancy command will also take an optional {{\-\-dont-reassign-primaries}} 
argument to determine if primaries should not be reassigned during the 
operation. The default behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 

[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-08 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7954:
---
Description: 
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * Redundancy is fully satisfied for all regions that were included, either 
explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
At least one bucket in a region has fewer than the configured number of 
redundant copies.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{\-\-include-region}} and 
{{\-\-exclude-region}} arguments, similar to the existing rebalance command. If 
neither argument is specified, all regions will be included. Included regions 
will take precedence over excluded regions when both are specified. The restore 
redundancy command will also take an optional {{\-\-reassign-primaries}} 
argument to determine if primaries should be reassigned or not during the 
operation. The default behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]

  was:
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * Redundancy is fully satisfied for all regions that were included, either 
explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
At least one bucket in a region has fewer than the configured number of 
redundant copies.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--reassign-primaries}} argument to determine if 
primaries should be reassigned or not during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 

[jira] [Updated] (GEODE-7953) Create Restore Redundancy Internal API

2020-04-09 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7953:
---
Component/s: regions

> Create Restore Redundancy Internal API
> --
>
> Key: GEODE-7953
> URL: https://issues.apache.org/jira/browse/GEODE-7953
> Project: Geode
>  Issue Type: New Feature
>  Components: regions
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Introduce an internal API to allow redundancy to be restored and primary 
> bucket hosts reassigned without necessitating a full rebalance.
> As described in the RFC found here: 
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands

2020-04-06 Thread Donal Evans (Jira)
Donal Evans created GEODE-7955:
--

 Summary: Documentation for restore redundancy internal API and 
gfsh commands
 Key: GEODE-7955
 URL: https://issues.apache.org/jira/browse/GEODE-7955
 Project: Geode
  Issue Type: Task
  Components: docs
Reporter: Donal Evans


Fully document the new features introduced in GEODE-7953 and GEODE-7954



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7955:
--

Assignee: Donal Evans

> Documentation for restore redundancy internal API and gfsh commands
> ---
>
> Key: GEODE-7955
> URL: https://issues.apache.org/jira/browse/GEODE-7955
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Fully document the new features introduced in GEODE-7953 and GEODE-7954



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7954:
---
Description: 
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{\-\-include-region}} and 
{{\-\-exclude-region}} arguments, similar to the existing rebalance command. If 
neither argument is specified, all regions will be included. Included regions 
will take precedence over excluded regions when both are specified. The restore 
redundancy command will also take an optional {{\-\-dont-reassign-primaries}} 
argument to determine if primaries should not be reassigned during the 
operation. The default behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]

  was:
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]


> Create restore redundancy 

[jira] [Assigned] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7954:
--

Assignee: Donal Evans

> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the 
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified 
> partitioned regions and trigger the restore redundancy operation for those 
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
>  * At least one redundant copy exists for every bucket in regions with 
> redundancy configured that were included, either explicitly or implicitly.
>  * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
>  * At least one bucket in a region has zero redundant copies, and that region 
> has redundancy configured.
>  * At least one of the explicitly included partitioned regions is not found.
>  * There is a member in the system with a version of Geode older than 1.13.0 
> (assuming that is the version in which this feature is implemented).
>  * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the 
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and 
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command. 
> If neither argument is specified, all regions will be included. Included 
> regions will take precedence over excluded regions when both are specified. 
> The restore redundancy command will also take an optional 
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not 
> be reassigned during the operation. The default behaviour will be to reassign 
> primaries.
> Both commands will output a list of regions with zero redundant copies first 
> (unless they are configured to have zero redundancy), then regions with less 
> than their configured redundancy, then regions with full redundancy. The 
> restore redundancy command will also output information about how many 
> primaries were reassigned and how long that process took, similar to the 
> existing rebalance command.
> As described here: 
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7953) Create Restore Redundancy Internal API

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7953:
--

Assignee: Donal Evans

> Create Restore Redundancy Internal API
> --
>
> Key: GEODE-7953
> URL: https://issues.apache.org/jira/browse/GEODE-7953
> Project: Geode
>  Issue Type: New Feature
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Introduce an internal API to allow redundancy to be restored and primary 
> bucket hosts reassigned without necessitating a full rebalance.
> As described in the RFC found here: 
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7954:
---
Description: 
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]

  was:
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region-}} and {{-exclude-region-}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{-dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]


> Create restore redundancy and 

[jira] [Updated] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7954:
---
Description: 
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region-}} and {{-exclude-region-}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{-dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]

  was:
Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)] }}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]


> Create restore redundancy and 

[jira] [Created] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)
Donal Evans created GEODE-7954:
--

 Summary: Create restore redundancy and status redundancy gfsh 
commands
 Key: GEODE-7954
 URL: https://issues.apache.org/jira/browse/GEODE-7954
 Project: Geode
  Issue Type: New Feature
  Components: gfsh
Reporter: Donal Evans


Add two gfsh commands to allow redundancy to be restored and to check the 
current redundancy status:

{{restore redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)] }}

{{status redundancy [--include-region=value(,value)*] 
[--exclude-region=value(,value)*]}}

The first command will execute a function on members hosting the specified 
partitioned regions and trigger the restore redundancy operation for those 
regions, then report the final redundancy status of those regions.

The command will return success status if:
 * At least one redundant copy exists for every bucket in regions with 
redundancy configured that were included, either explicitly or implicitly.
 * No partitioned regions were found and none were explicitly included.

The command will return error status if:
 * At least one bucket in a region has zero redundant copies, and that region 
has redundancy configured.
 * At least one of the explicitly included partitioned regions is not found.
 * There is a member in the system with a version of Geode older than 1.13.0 
(assuming that is the version in which this feature is implemented).
 * The restore redundancy function encounters an exception.

The second command will determine the current redundancy status for the 
specified regions and report it to the user.

Both commands will take optional {{--include-region}} and {{--exclude-region}} 
arguments, similar to the existing rebalance command. If neither argument is 
specified, all regions will be included. Included regions will take precedence 
over excluded regions when both are specified. The restore redundancy command 
will also take an optional {{--dont-reassign-primaries}} argument to determine 
if primaries should not be reassigned during the operation. The default 
behaviour will be to reassign primaries.

Both commands will output a list of regions with zero redundant copies first 
(unless they are configured to have zero redundancy), then regions with less 
than their configured redundancy, then regions with full redundancy. The 
restore redundancy command will also output information about how many 
primaries were reassigned and how long that process took, similar to the 
existing rebalance command.

As described here: 
[https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7953) Create Restore Redundancy Internal API

2020-04-06 Thread Donal Evans (Jira)
Donal Evans created GEODE-7953:
--

 Summary: Create Restore Redundancy Internal API
 Key: GEODE-7953
 URL: https://issues.apache.org/jira/browse/GEODE-7953
 Project: Geode
  Issue Type: New Feature
Reporter: Donal Evans


Introduce an internal API to allow redundancy to be restored and primary bucket 
hosts reassigned without necessitating a full rebalance.

As described in the RFC found here: 
https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7954:


It will be possible for a user to determine if full redundancy has been 
satisfied by looking at the result of the command. If the command returns 
success and there is no info section for members with partially satisfied 
redundancy, then they know that all included regions have fully satisfied 
redundancy.

As a side note, it would have been better timing if this feedback had been 
provided during the RFC discussion process, since that's where the design 
details were intended to be hammered out and agreed on. Changes can be made, of 
course, but there is already consensus on the proposed design at this point.

> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the 
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified 
> partitioned regions and trigger the restore redundancy operation for those 
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
>  * At least one redundant copy exists for every bucket in regions with 
> redundancy configured that were included, either explicitly or implicitly.
>  * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
>  * At least one bucket in a region has zero redundant copies, and that region 
> has redundancy configured.
>  * At least one of the explicitly included partitioned regions is not found.
>  * There is a member in the system with a version of Geode older than 1.13.0 
> (assuming that is the version in which this feature is implemented).
>  * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the 
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and 
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command. 
> If neither argument is specified, all regions will be included. Included 
> regions will take precedence over excluded regions when both are specified. 
> The restore redundancy command will also take an optional 
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not 
> be reassigned during the operation. The default behaviour will be to reassign 
> primaries.
> Both commands will output a list of regions with zero redundant copies first 
> (unless they are configured to have zero redundancy), then regions with less 
> than their configured redundancy, then regions with full redundancy. The 
> restore redundancy command will also output information about how many 
> primaries were reassigned and how long that process took, similar to the 
> existing rebalance command.
> As described here: 
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-04-06 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7954:


{quote}Do this mean if redundancy is configured for 2 redundant copies, restore 
redundancy command would return successfully if there is only one redundant 
copy in the cluster?
{quote}
The command will return success status, yes. But the output will also include 
information about how many regions do not have fully satisfied redundancy (if 
any), so it will be clear to the user what the state of the system is.

The reasoning behind this is that as long as one redundant copy exists, we have 
redundancy, although we may not have as much redundancy as we would ideally 
want (if it's below the configured level), and so we have protection from data 
loss in the event that we lose a member from the system. The difference between 
fully satisfied redundancy (x out of x configured copies exist for each bucket) 
and partially satisfied redundancy (at least 1 out of x configured copies exist 
for each bucket) is much less critical than the difference between partially 
satisfied redundancy and zero redundant copies existing at all, where if we 
lose a member, we lose all data on that member.

> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> Add two gfsh commands to allow redundancy to be restored and to check the 
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*] [--dont-reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified 
> partitioned regions and trigger the restore redundancy operation for those 
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
>  * At least one redundant copy exists for every bucket in regions with 
> redundancy configured that were included, either explicitly or implicitly.
>  * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
>  * At least one bucket in a region has zero redundant copies, and that region 
> has redundancy configured.
>  * At least one of the explicitly included partitioned regions is not found.
>  * There is a member in the system with a version of Geode older than 1.13.0 
> (assuming that is the version in which this feature is implemented).
>  * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the 
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and 
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command. 
> If neither argument is specified, all regions will be included. Included 
> regions will take precedence over excluded regions when both are specified. 
> The restore redundancy command will also take an optional 
> {{\-\-dont-reassign-primaries}} argument to determine if primaries should not 
> be reassigned during the operation. The default behaviour will be to reassign 
> primaries.
> Both commands will output a list of regions with zero redundant copies first 
> (unless they are configured to have zero redundancy), then regions with less 
> than their configured redundancy, then regions with full redundancy. The 
> restore redundancy command will also output information about how many 
> primaries were reassigned and how long that process took, similar to the 
> existing rebalance command.
> As described here: 
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7980) Incorrect member count in rebalance output when rebalancing colocated regions

2020-04-10 Thread Donal Evans (Jira)
Donal Evans created GEODE-7980:
--

 Summary: Incorrect member count in rebalance output when 
rebalancing colocated regions 
 Key: GEODE-7980
 URL: https://issues.apache.org/jira/browse/GEODE-7980
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


When colocated regions are present during rebalance, incorrect member counts 
are reported in the rebalance results:

 
{code:java}
[vm0] [info 2020/04/10 11:28:50.895 PDT  tid=0x56] 
Rebalanced partition regions /childRegion
 [vm0] Total bytes in all redundant bucket copies created during this rebalance 
= 0
 [vm0] Total time (in milliseconds) spent creating redundant bucket copies 
during this rebalance = 0
 [vm0] Total number of redundant copies created during this rebalance = 0
 [vm0] Total bytes in buckets moved during this rebalance = 0
 [vm0] Total time (in milliseconds) spent moving buckets during this rebalance 
= 0
 [vm0] Total number of buckets moved during this rebalance = 0
 [vm0] Total time (in milliseconds) spent switching the primary state of 
buckets during this rebalance = 0
 [vm0] Total primaries transferred during this rebalance = 0
 [vm0] Total time (in milliseconds) for this rebalance = 0
 [vm0] Total number of members in system on which rebalance is executed = 0
[vm0] [info 2020/04/10 11:28:50.896 PDT  tid=0x56] 
Rebalanced partition regions /parentRegion
 [vm0] Total bytes in all redundant bucket copies created during this rebalance 
= 0
 [vm0] Total time (in milliseconds) spent creating redundant bucket copies 
during this rebalance = 0
 [vm0] Total number of redundant copies created during this rebalance = 0
 [vm0] Total bytes in buckets moved during this rebalance = 18426
 [vm0] Total time (in milliseconds) spent moving buckets during this rebalance 
= 2715
 [vm0] Total number of buckets moved during this rebalance = 132
 [vm0] Total time (in milliseconds) spent switching the primary state of 
buckets during this rebalance = 0
 [vm0] Total primaries transferred during this rebalance = 0
 [vm0] Total time (in milliseconds) for this rebalance = 5506
 [vm0] Total number of members in system on which rebalance is executed = 4
{code}
 

 

A test to reproduce the issue is provided below.
{code:java}
public class RebalanceMembersColocationTest {

  public static final String PARENT_REGION_NAME = "parentRegion";
  public static final String CHILD_REGION_NAME = "childRegion";
  @Rule
  public ClusterStartupRule cluster = new ClusterStartupRule();

  @Rule
  public GfshCommandRule gfsh = new GfshCommandRule();

  @Test
  public void testRebalanceResultOutputMemberCountWIthColocatedRegions() throws 
Exception {
MemberVM locator = cluster.startLocatorVM(0);

MemberVM server1 = cluster.startServerVM(1, locator.getPort());
MemberVM server2 = cluster.startServerVM(2, locator.getPort());

server1.invoke(() -> {
  Region parentRegion = 
Objects.requireNonNull(ClusterStartupRule.getCache())
  
.createRegionFactory(RegionShortcut.PARTITION).create(PARENT_REGION_NAME);

  IntStream.range(0, 500).forEach(i -> parentRegion.put("key" + i, "value" 
+ 1));

  PartitionAttributesImpl attributes = new PartitionAttributesImpl();
  attributes.setColocatedWith(PARENT_REGION_NAME);

  Region childRegion = 
Objects.requireNonNull(ClusterStartupRule.getCache())
  
.createRegionFactory(RegionShortcut.PARTITION).setPartitionAttributes(attributes)
  .create(CHILD_REGION_NAME);

  IntStream.range(0, 500).forEach(i -> childRegion.put("key" + i, "value" + 
1));
});

server2.invoke(() -> {
  Objects.requireNonNull(ClusterStartupRule.getCache())
  
.createRegionFactory(RegionShortcut.PARTITION).create(PARENT_REGION_NAME);

  PartitionAttributesImpl attributes = new PartitionAttributesImpl();
  attributes.setColocatedWith(PARENT_REGION_NAME);

  Objects.requireNonNull(ClusterStartupRule.getCache())
  
.createRegionFactory(RegionShortcut.PARTITION).setPartitionAttributes(attributes)
  .create(CHILD_REGION_NAME);
});

locator.waitUntilRegionIsReadyOnExactlyThisManyServers("/" + 
PARENT_REGION_NAME, 2);
locator.waitUntilRegionIsReadyOnExactlyThisManyServers("/" + 
CHILD_REGION_NAME, 2);

gfsh.connectAndVerify(locator);

Map> rebalanceResult = 
gfsh.executeAndAssertThat("rebalance")
.statusIsSuccess().hasTableSection().getActual().getContent();

assertThat(rebalanceResult.get("Value").get(9)).isEqualTo("2");
  }
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7905) RedisDistDUnitTest failing intermittently in CI

2020-03-27 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7905:
--

Assignee: Raymond Ingles

> RedisDistDUnitTest failing intermittently in CI
> ---
>
> Key: GEODE-7905
> URL: https://issues.apache.org/jira/browse/GEODE-7905
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Sarah Abbey
>Assignee: Raymond Ingles
>Priority: Major
>
> Fix RedisDistDUnitTest, which fails intermittently:
>  [https://concourse.apachegeode-ci.info/builds/141130]
>  
> {code:java}
> org.apache.geode.redis.RedisDistDUnitTest > classMethod FAILED
>  java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
>  Fix the strings or use IgnoredException.addIgnoredException to ignore.
>  ---
>  Found suspect string in log4j at line 5030
> [error 2020/03/23 19:26:51.559 GMT  tid=99] 
> org.apache.geode.ToDataException: toData failed on DataSerializer with id=0 
> for class class java.util.HashSet
> 6 tests completed, 1 failed
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-6504) CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED

2020-03-27 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-6504:


Reoccurred: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK8/builds/881

> CI: RegionExpirationIntegrationTest > increaseRegionTtl[EMPTY] FAILED
> -
>
> Key: GEODE-6504
> URL: https://issues.apache.org/jira/browse/GEODE-6504
> Project: Geode
>  Issue Type: Bug
>  Components: expiration
>Reporter: Mark Hanson
>Assignee: Kirk Lund
>Priority: Major
> Attachments: RegionExpirationIntegrationTest.log
>
>
> CI failure:  see attached log.
>  
> Failed on WindowsIntegrationTestOpenJDK11  
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/272]
> {noformat}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[EMPTY] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88)
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-6935) RegionExpirationIntegrationTest#increaseRegionTtl fails intermittently

2020-03-27 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-6935.

Resolution: Duplicate

> RegionExpirationIntegrationTest#increaseRegionTtl fails intermittently
> --
>
> Key: GEODE-6935
> URL: https://issues.apache.org/jira/browse/GEODE-6935
> Project: Geode
>  Issue Type: Bug
>Reporter: Murtuza Boxwala
>Priority: Major
>
> The test relies on specific timings.  If the AttributesMutator takes longer 
> than expected, the region will be destroyed before its TTL is updated, 
> resulting in the below:
> {code:java}
> org.apache.geode.cache.RegionExpirationIntegrationTest > 
> increaseRegionTtl[NORMAL] FAILED
> java.lang.AssertionError: 
> Expecting:
>  <7L>
> to be greater than or equal to:
>  <8L> 
> at 
> org.apache.geode.cache.RegionExpirationIntegrationTest.increaseRegionTtl(RegionExpirationIntegrationTest.java:88){code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsCoreIntegrationTestOpenJDK11/builds/104



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-7905) RedisDistDUnitTest failing intermittently in CI

2020-03-27 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-7905:


Reoccurred: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1684

> RedisDistDUnitTest failing intermittently in CI
> ---
>
> Key: GEODE-7905
> URL: https://issues.apache.org/jira/browse/GEODE-7905
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Sarah Abbey
>Priority: Major
>
> Fix RedisDistDUnitTest, which fails intermittently:
>  [https://concourse.apachegeode-ci.info/builds/141130]
>  
> {code:java}
> org.apache.geode.redis.RedisDistDUnitTest > classMethod FAILED
>  java.lang.AssertionError: Suspicious strings were written to the log during 
> this run.
>  Fix the strings or use IgnoredException.addIgnoredException to ignore.
>  ---
>  Found suspect string in log4j at line 5030
> [error 2020/03/23 19:26:51.559 GMT  tid=99] 
> org.apache.geode.ToDataException: toData failed on DataSerializer with id=0 
> for class class java.util.HashSet
> 6 tests completed, 1 failed
> {code}
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7953) Create Restore Redundancy Internal API

2020-04-27 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7953.

Fix Version/s: 1.13.0
   Resolution: Implemented

> Create Restore Redundancy Internal API
> --
>
> Key: GEODE-7953
> URL: https://issues.apache.org/jira/browse/GEODE-7953
> Project: Geode
>  Issue Type: New Feature
>  Components: regions
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.13.0
>
>  Time Spent: 3.5h
>  Remaining Estimate: 0h
>
> Introduce an internal API to allow redundancy to be restored and primary 
> bucket hosts reassigned without necessitating a full rebalance.
> As described in the RFC found here: 
> https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator

2020-04-27 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-8031:
--

Assignee: Donal Evans

> CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator 
> fails due to SSL not enabled for locator
> --
>
> Key: GEODE-8031
> URL: https://issues.apache.org/jira/browse/GEODE-8031
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > 
> testNewSSLConfigSSLComponentLocator FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)
> This failure is possibly caused by previously run tests not closing the 
> static SocketCreatorFactory instance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator

2020-04-27 Thread Donal Evans (Jira)
Donal Evans created GEODE-8031:
--

 Summary: CI Failure: 
SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to 
SSL not enabled for locator
 Key: GEODE-8031
 URL: https://issues.apache.org/jira/browse/GEODE-8031
 Project: Geode
  Issue Type: Bug
Reporter: Donal Evans


org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > 
testNewSSLConfigSSLComponentLocator FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at 
org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)

This failure is possibly caused by previously run tests not closing the static 
SocketCreatorFactory instance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to SSL not enabled for locator

2020-04-27 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-8031:
---
Affects Version/s: 1.13.0

> CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator 
> fails due to SSL not enabled for locator
> --
>
> Key: GEODE-8031
> URL: https://issues.apache.org/jira/browse/GEODE-8031
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Donal Evans
>Priority: Major
>
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > 
> testNewSSLConfigSSLComponentLocator FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)
> This failure is possibly caused by previously run tests not closing the 
> static SocketCreatorFactory instance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator

2020-04-27 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-8031:
---
Summary: CI Failure: 
SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on 
Windows due to SSL not enabled for locator  (was: CI Failure: 
SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails due to 
SSL not enabled for locator)

> CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator 
> fails on Windows due to SSL not enabled for locator
> -
>
> Key: GEODE-8031
> URL: https://issues.apache.org/jira/browse/GEODE-8031
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
>
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > 
> testNewSSLConfigSSLComponentLocator FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)
> This failure is possibly caused by previously run tests not closing the 
> static SocketCreatorFactory instance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-8031) CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator fails on Windows due to SSL not enabled for locator

2020-04-27 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-8031.

Fix Version/s: 1.13.0
   Resolution: Fixed

> CI Failure: SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator 
> fails on Windows due to SSL not enabled for locator
> -
>
> Key: GEODE-8031
> URL: https://issues.apache.org/jira/browse/GEODE-8031
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.13.0
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.13.0
>
>
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest > 
> testNewSSLConfigSSLComponentLocator FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at 
> org.apache.geode.internal.net.SocketCreatorFactoryJUnitTest.testNewSSLConfigSSLComponentLocator(SocketCreatorFactoryJUnitTest.java:106)
> This failure is possibly caused by previously run tests not closing the 
> static SocketCreatorFactory instance.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8141) Move definition of Region separator character to geode-common and make usage consistent throughout the codebase

2020-05-17 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-8141:
---
Description: 
The separator character for region paths is currently defined in the Region 
interface in geode-core. However, geode-management, which does not have a 
dependency on geode-core, uses the separator in several classes.

* The definitions of the separator character and string should be moved to the 
geode-common module.
* The currently existing definitions of the separator in the geode-core Region 
interface should be deprecated. 
* All instances of hardcoded '/' characters and strings should be replaced with 
references to the constants in geode-common. 

  was:
The separator character for region paths is currently defined in the Region 
interface in geode-core. However, geode-management, which does not have a 
dependency on geode-core, uses the separator in several classes.

* The definitions of the separator character and string should be moved to the 
geode-common module.
* The currently existing definitions of the separator in the geode-core Region 
class should be deprecated. 
* All instances of hardcoded '/' characters and strings should be replaced with 
references to the constants in geode-common. 


> Move definition of Region separator character to geode-common and make usage 
> consistent throughout the codebase
> ---
>
> Key: GEODE-8141
> URL: https://issues.apache.org/jira/browse/GEODE-8141
> Project: Geode
>  Issue Type: Task
>Reporter: Donal Evans
>Priority: Major
>
> The separator character for region paths is currently defined in the Region 
> interface in geode-core. However, geode-management, which does not have a 
> dependency on geode-core, uses the separator in several classes.
> * The definitions of the separator character and string should be moved to 
> the geode-common module.
> * The currently existing definitions of the separator in the geode-core 
> Region interface should be deprecated. 
> * All instances of hardcoded '/' characters and strings should be replaced 
> with references to the constants in geode-common. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-8141) Move definition of Region separator character to geode-common and make usage consistent throughout the codebase

2020-05-17 Thread Donal Evans (Jira)
Donal Evans created GEODE-8141:
--

 Summary: Move definition of Region separator character to 
geode-common and make usage consistent throughout the codebase
 Key: GEODE-8141
 URL: https://issues.apache.org/jira/browse/GEODE-8141
 Project: Geode
  Issue Type: Task
Reporter: Donal Evans


The separator character for region paths is currently defined in the Region 
interface in geode-core. However, geode-management, which does not have a 
dependency on geode-core, uses the separator in several classes.

* The definitions of the separator character and string should be moved to the 
geode-common module.
* The currently existing definitions of the separator in the geode-core Region 
class should be deprecated. 
* All instances of hardcoded '/' characters and strings should be replaced with 
references to the constants in geode-common. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-7860) Indexed query benchmarks fail with EOFException

2020-03-09 Thread Donal Evans (Jira)
Donal Evans created GEODE-7860:
--

 Summary: Indexed query benchmarks fail with EOFException
 Key: GEODE-7860
 URL: https://issues.apache.org/jira/browse/GEODE-7860
 Project: Geode
  Issue Type: Bug
  Components: benchmarks, querying
Reporter: Donal Evans


{noformat}
org.apache.geode.benchmark.tests.ReplicatedIndexedQueryBenchmark > run() FAILED
java.util.concurrent.CompletionException: java.lang.RuntimeException: 
java.rmi.UnmarshalException: Error unmarshaling return header; nested exception 
is: 
  java.io.EOFException

Caused by:
java.lang.RuntimeException: java.rmi.UnmarshalException: Error 
unmarshaling return header; nested exception is: 
  java.io.EOFException

Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header; 
nested exception is: 
  java.io.EOFException

Caused by:
java.io.EOFException

16 tests completed, 1 failed
org.apache.geode.benchmark.tests.PartitionedIndexedQueryBenchmark > run() FAILED
java.util.concurrent.CompletionException: java.lang.RuntimeException: 
java.rmi.UnmarshalException: Error unmarshaling return header; nested exception 
is: 
  java.io.EOFException

Caused by:
java.lang.RuntimeException: java.rmi.UnmarshalException: Error 
unmarshaling return header; nested exception is: 
  java.io.EOFException

Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header; 
nested exception is: 
  java.io.EOFException

Caused by:
java.io.EOFException

16 tests completed, 1 failed
{noformat}

Failure seen in this run: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/Benchmark_base/builds/146
 but was passing in the following run.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7680) Partitioned region clear operations must be successful while interacting with rebalance

2020-05-06 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7680:
---
Labels: GeodeCommons caching-applications  (was: GeodeCommons)

> Partitioned region clear operations must be successful while interacting with 
> rebalance 
> 
>
> Key: GEODE-7680
> URL: https://issues.apache.org/jira/browse/GEODE-7680
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Nabarun Nag
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons, caching-applications
>
> Clear operations are successful and while rebalance operations are ongoing.
> Acceptance :
>  * DUnit tests validating the above behavior.
>  * Test coverage to when a member departs in this scenario
>  * Test coverage to when a member restarts in this scenario
>  * Unit tests with complete code coverage for the newly written code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-7680) Partitioned region clear operations must be successful while interacting with rebalance

2020-05-06 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-7680:
--

Assignee: Donal Evans

> Partitioned region clear operations must be successful while interacting with 
> rebalance 
> 
>
> Key: GEODE-7680
> URL: https://issues.apache.org/jira/browse/GEODE-7680
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Nabarun Nag
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
>
> Clear operations are successful and while rebalance operations are ongoing.
> Acceptance :
>  * DUnit tests validating the above behavior.
>  * Test coverage to when a member departs in this scenario
>  * Test coverage to when a member restarts in this scenario
>  * Unit tests with complete code coverage for the newly written code.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived

2020-05-21 Thread Donal Evans (Jira)


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

Donal Evans commented on GEODE-8172:


Failed again here: 
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/192#A

Likely a flaky test introduced by https://github.com/apache/geode/pull/4387

> CI failure: 
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce J Schuchardt
>Priority: Major
>
> Failed in a CI run 
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN 
> changes could be detected.  Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
>  > 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
>  in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.wan.WANTestBase that uses int, 
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5 
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-8172) CI failure: ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived

2020-05-21 Thread Donal Evans (Jira)


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

Donal Evans reassigned GEODE-8172:
--

Assignee: Mario Ivanac

> CI failure: 
> ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> ---
>
> Key: GEODE-8172
> URL: https://issues.apache.org/jira/browse/GEODE-8172
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Ivanac
>Priority: Major
>
> Failed in a CI run 
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/191#A).
> No previous failures for this issue are found in JIRA and no recent WAN 
> changes could be detected.  Flaky?
> {noformat}
> > Task :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.offheap.ParallelWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
>  > 
> testpersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived 
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.parallel.ParallelWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$487/908301056.run
>  in VM 2 running on Host 8e35f765a792 with 8 VMs
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition 
> defined as a lambda expression in 
> org.apache.geode.internal.cache.wan.WANTestBase that uses int, 
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20> within 5 
> minutes.
> Caused by:
> java.lang.AssertionError: Expected region entries: 0 but actual 
> entries: 20 present region keyset [3, 5, 8, 13, 16, 21, 27, 30, 35, 38, 43, 
> 45, 50, 54, 58, 62, 65, 68, 73, 78] expected:<0> but was:<20>
> 824 tests completed, 1 failed, 59 skipped
> > Task :geode-wan:distributedTest FAILED
> {noformat}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7954) Create restore redundancy and status redundancy gfsh commands

2020-05-01 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7954.

Fix Version/s: 1.13.0
   Resolution: Implemented

> Create restore redundancy and status redundancy gfsh commands
> -
>
> Key: GEODE-7954
> URL: https://issues.apache.org/jira/browse/GEODE-7954
> Project: Geode
>  Issue Type: New Feature
>  Components: gfsh
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.13.0
>
>
> Add two gfsh commands to allow redundancy to be restored and to check the 
> current redundancy status:
> {{restore redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*] [--reassign-primaries(=value)]}}
> {{status redundancy [--include-region=value(,value)*] 
> [--exclude-region=value(,value)*]}}
> The first command will execute a function on members hosting the specified 
> partitioned regions and trigger the restore redundancy operation for those 
> regions, then report the final redundancy status of those regions.
> The command will return success status if:
>  * Redundancy is fully satisfied for all regions that were included, either 
> explicitly or implicitly.
>  * No partitioned regions were found and none were explicitly included.
> The command will return error status if:
>  * At least one bucket in a region has zero redundant copies, and that region 
> has redundancy configured.
> At least one bucket in a region has fewer than the configured number of 
> redundant copies.
>  * At least one of the explicitly included partitioned regions is not found.
>  * There is a member in the system with a version of Geode older than 1.13.0 
> (assuming that is the version in which this feature is implemented).
>  * The restore redundancy function encounters an exception.
> The second command will determine the current redundancy status for the 
> specified regions and report it to the user.
> Both commands will take optional {{\-\-include-region}} and 
> {{\-\-exclude-region}} arguments, similar to the existing rebalance command. 
> If neither argument is specified, all regions will be included. Included 
> regions will take precedence over excluded regions when both are specified. 
> The restore redundancy command will also take an optional 
> {{\-\-reassign-primaries}} argument to determine if primaries should be 
> reassigned or not during the operation. The default behaviour will be to 
> reassign primaries.
> Both commands will output a list of regions with zero redundant copies first 
> (unless they are configured to have zero redundancy), then regions with less 
> than their configured redundancy, then regions with full redundancy. The 
> restore redundancy command will also output information about how many 
> primaries were reassigned and how long that process took, similar to the 
> existing rebalance command.
> As described here: 
> [https://cwiki.apache.org/confluence/display/GEODE/Redundancy+Gfsh+Commands]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-7955) Documentation for restore redundancy internal API and gfsh commands

2020-05-01 Thread Donal Evans (Jira)


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

Donal Evans resolved GEODE-7955.

Fix Version/s: 1.13.0
   Resolution: Done

> Documentation for restore redundancy internal API and gfsh commands
> ---
>
> Key: GEODE-7955
> URL: https://issues.apache.org/jira/browse/GEODE-7955
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Donal Evans
>Assignee: Donal Evans
>Priority: Major
> Fix For: 1.13.0
>
>
> Fully document the new features introduced in GEODE-7953 and GEODE-7954



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-8494) CI Failure: Tomcat7SessionsTest.setupClass fails due to java.net.BindException: Address already in use

2020-09-14 Thread Donal Evans (Jira)
Donal Evans created GEODE-8494:
--

 Summary: CI Failure: Tomcat7SessionsTest.setupClass fails due to 
java.net.BindException: Address already in use
 Key: GEODE-8494
 URL: https://issues.apache.org/jira/browse/GEODE-8494
 Project: Geode
  Issue Type: Bug
Affects Versions: 1.14.0
Reporter: Donal Evans


This is possibly just an unlucky port collision due to multiple tests being run 
at the same time.
{noformat}
org.apache.geode.modules.session.Tomcat7SessionsTest > classMethod FAILED
org.apache.catalina.LifecycleException: service.getName(): "null";  
Protocol handler start failed
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:986)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Embedded.startInternal(Embedded.java:781)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.geode.modules.session.EmbeddedTomcat.startContainer(EmbeddedTomcat.java:98)
at 
org.apache.geode.modules.session.AbstractSessionsTest.setupServer(AbstractSessionsTest.java:71)
at 
org.apache.geode.modules.session.Tomcat7SessionsTest.setupClass(Tomcat7SessionsTest.java:36)

Caused by:
java.net.BindException: Address already in use: NET_Bind :49811
at org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:414)
at 
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:767)
at 
org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:482)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:979)
... 6 more

Caused by:
java.net.BindException: Address already in use: NET_Bind
at java.net.PlainSocketImpl.bind0(Native Method)
at java.net.PlainSocketImpl.socketBind(PlainSocketImpl.java:132)
at 
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:436)
at java.net.ServerSocket.bind(ServerSocket.java:395)
at java.net.ServerSocket.(ServerSocket.java:257)
at java.net.ServerSocket.(ServerSocket.java:201)
at 
org.apache.tomcat.util.net.DefaultServerSocketFactory.createSocket(DefaultServerSocketFactory.java:49)
at 
org.apache.tomcat.util.net.JIoEndpoint.bind(JIoEndpoint.java:401)
... 9 more
{noformat}
 
 =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 
[http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0330/test-results/integrationTest/1600111592/]
 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

[http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0330/test-artifacts/1600111592/windows-integrationtestfiles-OpenJDK11-1.14.0-build.0330.tgz]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-7524) CI failure: hang in FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange

2020-09-14 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-7524:
---
Labels: flaky  (was: )

> CI failure: hang in 
> FreeListOffHeapRegionJUnitTest.testPersistentCompressorChange
> -
>
> Key: GEODE-7524
> URL: https://issues.apache.org/jira/browse/GEODE-7524
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Bruce J Schuchardt
>Priority: Major
>  Labels: flaky
>
> This test hung in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1317]
> The test is stuck waiting for background persistence tasks to complete but 
> there are no background tasks in the thread dumps for the run.  Here's one 
> thread dump:
> {noformat}
> Container: quizzical_lamarr
> * Dumping stack for process 1:
> 2019-12-03 00:03:04
> Full thread dump OpenJDK 64-Bit Server VM 
> (11.0.4+11-post-Ubuntu-1ubuntu218.04.3 mixed mode, sharing):
> Threads class SMR info:
> _java_thread_list=0x7f1d7c001eb0, length=20, elements={
> 0x7f1dc8016800, 0x7f1dc83e0800, 0x7f1dc83e2800, 
> 0x7f1dc83ea000,
> 0x7f1dc83ec800, 0x7f1dc83f6800, 0x7f1dc83f8800, 
> 0x7f1dc844,
> 0x7f1dc844b000, 0x7f1dc8b2a000, 0x7f1dc8b4f000, 
> 0x7f1dc8b4a000,
> 0x7f1d54fc0800, 0x7f1d55347000, 0x7f1d54f94800, 
> 0x7f1d54fbf000,
> 0x7f1d54d73000, 0x7f1d54ffe000, 0x7f1d54fff800, 0x7f1d7c001000
> }
> "main" #1 prio=5 os_prio=0 cpu=762.76ms elapsed=1216.50s 
> tid=0x7f1dc8016800 nid=0x6 waiting on condition  [0x7f1dd068b000]
>java.lang.Thread.State: WAITING (parking)
>   at jdk.internal.misc.Unsafe.park(java.base@11.0.4/Native Method)
>   - parking to wait for  <0xd058e378> (a 
> java.util.concurrent.CountDownLatch$Sync)
>   at 
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.4/LockSupport.java:194)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.4/AbstractQueuedSynchronizer.java:885)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.4/AbstractQueuedSynchronizer.java:1039)
>   at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.4/AbstractQueuedSynchronizer.java:1345)
>   at 
> java.util.concurrent.CountDownLatch.await(java.base@11.0.4/CountDownLatch.java:232)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:72)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.execute(TestWorker.java:46)
>   at 
> org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:93)
>   at 
> org.gradle.process.internal.worker.child.ActionExecutionWorker.execute(ActionExecutionWorker.java:36)
>   at 
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:125)
>   at 
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:68)
>   at 
> worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:62)
>   at 
> worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:67)
>Locked ownable synchronizers:
>   - None
> "Reference Handler" #2 daemon prio=10 os_prio=0 cpu=4.10ms elapsed=1216.45s 
> tid=0x7f1dc83e0800 nid=0xd waiting on condition  [0x7f1d9c3c7000]
>java.lang.Thread.State: RUNNABLE
>   at 
> java.lang.ref.Reference.waitForReferencePendingList(java.base@11.0.4/Native 
> Method)
>   at 
> java.lang.ref.Reference.processPendingReferences(java.base@11.0.4/Reference.java:241)
>   at 
> java.lang.ref.Reference$ReferenceHandler.run(java.base@11.0.4/Reference.java:213)
>Locked ownable synchronizers:
>   - None
> "Finalizer" #3 daemon prio=8 os_prio=0 cpu=2.97ms elapsed=1216.45s 
> tid=0x7f1dc83e2800 nid=0xe in Object.wait()  [0x7f1d9c2c6000]
>java.lang.Thread.State: WAITING (on object monitor)
>   at java.lang.Object.wait(java.base@11.0.4/Native Method)
>   - waiting on 
>   at 
> java.lang.ref.ReferenceQueue.remove(java.base@11.0.4/ReferenceQueue.java:155)
>   - waiting to re-lock in wait() <0xd05927b0> (a 
> java.lang.ref.ReferenceQueue$Lock)
>   at 
> java.lang.ref.ReferenceQueue.remove(java.base@11.0.4/ReferenceQueue.java:176)
>   at 
> java.lang.ref.Finalizer$FinalizerThread.run(java.base@11.0.4/Finalizer.java:170)
>Locked ownable synchronizers:
>   - None
> "Signal Dispatcher" #4 daemon prio=9 

[jira] [Created] (GEODE-8617) org.apache.geode.test.dunit.VM.bounce() fails to restart VM with different Geode version due to EOFException

2020-10-15 Thread Donal Evans (Jira)
Donal Evans created GEODE-8617:
--

 Summary: org.apache.geode.test.dunit.VM.bounce() fails to restart 
VM with different Geode version due to EOFException
 Key: GEODE-8617
 URL: https://issues.apache.org/jira/browse/GEODE-8617
 Project: Geode
  Issue Type: Bug
Affects Versions: 1.12.0, 1.11.0, 1.9.0
Reporter: Donal Evans


This failure shows up in RollingUpgrade and BackwardsCompatibility tests 
occasionally when attempting to bounce a VM and restart it with a different 
version of Geode. The initial failure shows up as an {{EOFException}}, but 
subsequent runs of the same test with other versions (as part of the 
RollingUpgrade/BackwardsCompatibility test) fail with {{ConnectException: 
Connection refused (Connection refused)}}.

Two other tickets (GEODE-7142 and GEODE-6337) exist describing this failure in 
specific RollingUpgrade tests, but as it seems to be more general and not 
related to a specific test, this ticket has been created to consolidate them.

An example failure from a BackwardsCompatibility test is attached below.
{noformat}
> Task :geode-core:upgradeTest

org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
 > test[9] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.VM$$Lambda$30/1525819532.run in VM 3 running on 
Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.UnmarshalException: Error unmarshaling return header; nested 
exception is: 
  java.io.EOFException

Caused by:
java.io.EOFException

org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
 in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.lang.IllegalStateException: VM not available: VM 3 running on Host 
fad43bff7558 with 5 VMs with version 1.9.1

org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
 > test[10] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.VM$$Lambda$29/478086753.call in VM 3 running on 
Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49; 
nested exception is: 
  java.net.ConnectException: Connection refused (Connection refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
 in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49; 
nested exception is: 
  java.net.ConnectException: Connection refused (Connection refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
 > test[11] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running 
on Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49; 
nested exception is: 
  java.net.ConnectException: Connection refused (Connection refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.TxCommitMessageBCTestBase$$Lambda$44/1148702340.run
 in VM 3 running on Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49; 
nested exception is: 
  java.net.ConnectException: Connection refused (Connection refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

org.apache.geode.internal.cache.TxCommitMessageBCOldClientToServerTxPartitionTest
 > test[12] FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 3 running 
on Host fad43bff7558 with 5 VMs with version 1.9.1

Caused by:
java.rmi.ConnectException: Connection refused to host: 172.17.0.49; 
nested exception is: 
  java.net.ConnectException: Connection refused (Connection refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

org.apache.geode.test.dunit.RMIException: While invoking 

[jira] [Created] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"

2020-10-15 Thread Donal Evans (Jira)
Donal Evans created GEODE-8616:
--

 Summary: ClientServerCacheOperationDUnitTest > 
largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket 
timed out on client"
 Key: GEODE-8616
 URL: https://issues.apache.org/jira/browse/GEODE-8616
 Project: Geode
  Issue Type: Bug
Affects Versions: 1.12.1
Reporter: Donal Evans


{noformat}
> Task :geode-core:distributedTest

org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
 in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)

Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool 
unexpected socket timed out on client connection=Pooled Connection to 
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
connect after 1 attempts
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at 
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at 
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at 
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
at 
org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
at 
org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
at 
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
at 
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
at 
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
at 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
{noformat}

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

This is a flaky failure.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8616) ClientServerCacheOperationDUnitTest > largeObjectPutWithReadTimeoutThrowsException fails with "Pool unexpected socket timed out on client"

2020-10-15 Thread Donal Evans (Jira)


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

Donal Evans updated GEODE-8616:
---
Description: 
{noformat}
> Task :geode-core:distributedTest

org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
 in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)

Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool 
unexpected socket timed out on client connection=Pooled Connection to 
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
connect after 1 attempts
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at 
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at 
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at 
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
at 
org.apache.geode.internal.cache.LocalRegion.findObjectInSystem(LocalRegion.java:2795)
at 
org.apache.geode.internal.cache.LocalRegion.getObject(LocalRegion.java:1472)
at 
org.apache.geode.internal.cache.LocalRegion.nonTxnFindObject(LocalRegion.java:1445)
at 
org.apache.geode.internal.cache.LocalRegionDataView.findObject(LocalRegionDataView.java:196)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1382)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1321)
at 
org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1306)
at 
org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:436)
at 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.lambda$largeObjectPutWithReadTimeoutThrowsException$3ab01cf6$2(ClientServerCacheOperationDUnitTest.java:120)
{noformat}

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-results/distributedTest/1601514101/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

http://files.apachegeode-ci.info/builds/apache-support-1-12-main/1.12.1-build.0106/test-artifacts/1601514101/distributedtestfiles-OpenJDK11-1.12.1-build.0106.tgz

This is a flaky failure.

  was:
{noformat}
> Task :geode-core:distributedTest

org.apache.geode.cache30.ClientServerCacheOperationDUnitTest > 
largeObjectPutWithReadTimeoutThrowsException FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest$$Lambda$177/0x000100b52040.run
 in VM 2 running on Host c1346ab7b3e3 with 4 VMs
at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
at 
org.apache.geode.cache30.ClientServerCacheOperationDUnitTest.largeObjectPutWithReadTimeoutThrowsException(ClientServerCacheOperationDUnitTest.java:117)

Caused by:
org.apache.geode.cache.client.ServerConnectivityException: Pool 
unexpected socket timed out on client connection=Pooled Connection to 
c1346ab7b3e3:35437: Connection[DESTROYED]). Server unreachable: could not 
connect after 1 attempts
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:659)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:501)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:153)
at 
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at 
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at 
org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
at 
org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:116)
  

  1   2   3   4   5   6   7   8   >