[jira] [Resolved] (GEODE-7628) Block jmx mbean creation when no security manager is configured

2019-12-30 Thread Jinmei Liao (Jira)


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

Jinmei Liao resolved GEODE-7628.

Fix Version/s: 1.12.0
   Resolution: Fixed

> Block jmx mbean creation when no security manager is configured
> ---
>
> Key: GEODE-7628
> URL: https://issues.apache.org/jira/browse/GEODE-7628
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Affects Versions: 1.10.0
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When no security manager is configured, we should not allow any client to be 
> able to create mbeans.



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


[jira] [Assigned] (GEODE-7617) CI failure: GeodeClientClusterManagementSSLTest. getServiceUseClientSSLConfig

2019-12-30 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt reassigned GEODE-7617:
-

Assignee: (was: Bruce J Schuchardt)

> CI failure: GeodeClientClusterManagementSSLTest. getServiceUseClientSSLConfig
> -
>
> Key: GEODE-7617
> URL: https://issues.apache.org/jira/browse/GEODE-7617
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This test creates a locator and then creates a cache in another JVM and then 
> asserts that it can find the cluster configuration service.  The problem is 
> that the cluster configuration service is initialized in the background and 
> isn't ready when locator startup completes.  Until that guarantee is in place 
> this test is going to fail periodically because it makes the assertion 
> immediately after starting the locator.
> {noformat}
> org.apache.geode.management.internal.rest.GeodeClientClusterManagementSSLTest 
> > getServiceUseClientSSLConfig FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.internal.rest.GeodeClientClusterManagementSSLTest$$Lambda$29/1016886377.run
>  in VM 1 running on Host 3984d60ce841 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.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at 
> org.apache.geode.management.internal.rest.GeodeClientClusterManagementSSLTest.getServiceUseClientSSLConfig(GeodeClientClusterManagementSSLTest.java:67)
> Caused by:
> java.lang.IllegalStateException: Unable to discover a locator that 
> has ClusterManagementService running.
> at 
> org.apache.geode.management.internal.api.GeodeClusterManagementServiceBuilder.setClientCache(GeodeClusterManagementServiceBuilder.java:149)
> at 
> org.apache.geode.management.internal.api.GeodeClusterManagementServiceBuilder.setCache(GeodeClusterManagementServiceBuilder.java:89)
> at 
> org.apache.geode.management.internal.api.GeodeClusterManagementServiceBuilder.setCache(GeodeClusterManagementServiceBuilder.java:58)
> at 
> org.apache.geode.management.internal.rest.GeodeClientClusterManagementSSLTest.lambda$getServiceUseClientSSLConfig$bb17a952$1(GeodeClientClusterManagementSSLTest.java:69)
> {noformat}



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


[jira] [Resolved] (GEODE-7541) Break dependency on SocketCreator/Factory & SecurableCommunicationChannel

2019-12-30 Thread Dan Smith (Jira)


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

Dan Smith resolved GEODE-7541.
--
Fix Version/s: 1.12.0
   Resolution: Fixed

> Break dependency on SocketCreator/Factory & SecurableCommunicationChannel
> -
>
> Key: GEODE-7541
> URL: https://issues.apache.org/jira/browse/GEODE-7541
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> SocketCreator & SocketCreatorFactory.
> {color:#a8c023}which should also allow for break dependency on 
> internal.security{color}SecurableCommunicationChannel
>  
> Also look at usage of
> {code:java}
> OSProcess {code}
> in JGroupsMessenger
> {code:java}
> SocketCreator.resolve_dns ? 
> SocketCreator.getHostName(jgAddress.getInetAddress())
>  : jgAddress.getInetAddress().getHostAddress();
> GMSMemberData gmsMember = new GMSMemberData(jgAddress.getInetAddress(),
>  hostname, jgAddress.getPort(),
>  OSProcess.getId(),{code}



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


[jira] [Resolved] (GEODE-7546) Break dependencies in JGroupsMessenger

2019-12-30 Thread Dan Smith (Jira)


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

Dan Smith resolved GEODE-7546.
--
Fix Version/s: 1.12.0
   Resolution: Fixed

> Break dependencies in JGroupsMessenger
> --
>
> Key: GEODE-7546
> URL: https://issues.apache.org/jira/browse/GEODE-7546
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Ernest Burghardt
>Priority: Major
> Fix For: 1.12.0
>
>




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


[jira] [Created] (GEODE-7629) Break dependency on SecurableCommunicationChannel in Membership

2019-12-30 Thread Dan Smith (Jira)
Dan Smith created GEODE-7629:


 Summary: Break dependency on SecurableCommunicationChannel in 
Membership
 Key: GEODE-7629
 URL: https://issues.apache.org/jira/browse/GEODE-7629
 Project: Geode
  Issue Type: Improvement
  Components: membership
Reporter: Dan Smith






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


[jira] [Created] (GEODE-7630) Break dependency on OSProcess in membership

2019-12-30 Thread Dan Smith (Jira)
Dan Smith created GEODE-7630:


 Summary: Break dependency on OSProcess in membership
 Key: GEODE-7630
 URL: https://issues.apache.org/jira/browse/GEODE-7630
 Project: Geode
  Issue Type: Improvement
  Components: membership
Reporter: Dan Smith






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


[jira] [Resolved] (GEODE-7554) Benchmark CI: rerun failed tests

2019-12-30 Thread Helena Bales (Jira)


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

Helena Bales resolved GEODE-7554.
-
Fix Version/s: 1.11.0
   Resolution: Fixed

> Benchmark CI: rerun failed tests
> 
>
> Key: GEODE-7554
> URL: https://issues.apache.org/jira/browse/GEODE-7554
> Project: Geode
>  Issue Type: Improvement
>  Components: benchmarks
>Reporter: Helena Bales
>Assignee: Helena Bales
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> When tests run in CI fail, they will be written to a file. Read that file and 
> rerun the failed tests until the list is empty, or until the run has been 
> retried 5 times. Any tests that fail 5 times in a row are not flaky and need 
> to be addressed.



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


[jira] [Commented] (GEODE-7560) LGTM Issues with JTAUtils.java

2019-12-30 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-7560:


Commit 412c23cf0fde2c4dc18b5be50675c64dd7a64ec6 in geode's branch 
refs/heads/develop from M. Oleske
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=412c23c ]

GEODE-7560: Fix LGTM JTAUtils Issues (#4413)

* Remove unused container
* Remove empty conditional
* Use try with resources
* Rewrite do while loop without a break to help LGTM
* Remove unused functions from internal class
* Remove unneeded variables and deprecated usages
* Cleanup names/spellings

Authored-by: Michael Oleske 

> LGTM Issues with JTAUtils.java
> --
>
> Key: GEODE-7560
> URL: https://issues.apache.org/jira/browse/GEODE-7560
> Project: Geode
>  Issue Type: Improvement
>Reporter: Michael Oleske
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://lgtm.com/projects/g/apache/geode/snapshot/34f63b2c4d9c643a4c099ce7e1bf544d3f51e719/files/geode-junit/src/main/java/org/apache/geode/internal/jta/JTAUtils.java?sort=name&dir=ASC&mode=heatmap



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


[jira] [Resolved] (GEODE-7560) LGTM Issues with JTAUtils.java

2019-12-30 Thread Michael Oleske (Jira)


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

Michael Oleske resolved GEODE-7560.
---
Fix Version/s: 1.12.0
   Resolution: Done

> LGTM Issues with JTAUtils.java
> --
>
> Key: GEODE-7560
> URL: https://issues.apache.org/jira/browse/GEODE-7560
> Project: Geode
>  Issue Type: Improvement
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://lgtm.com/projects/g/apache/geode/snapshot/34f63b2c4d9c643a4c099ce7e1bf544d3f51e719/files/geode-junit/src/main/java/org/apache/geode/internal/jta/JTAUtils.java?sort=name&dir=ASC&mode=heatmap



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


[jira] [Assigned] (GEODE-7560) LGTM Issues with JTAUtils.java

2019-12-30 Thread Michael Oleske (Jira)


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

Michael Oleske reassigned GEODE-7560:
-

Assignee: Michael Oleske

> LGTM Issues with JTAUtils.java
> --
>
> Key: GEODE-7560
> URL: https://issues.apache.org/jira/browse/GEODE-7560
> Project: Geode
>  Issue Type: Improvement
>Reporter: Michael Oleske
>Assignee: Michael Oleske
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> https://lgtm.com/projects/g/apache/geode/snapshot/34f63b2c4d9c643a4c099ce7e1bf544d3f51e719/files/geode-junit/src/main/java/org/apache/geode/internal/jta/JTAUtils.java?sort=name&dir=ASC&mode=heatmap



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


[jira] [Created] (GEODE-7631) It's better to change the stuck to running in ThreadsMonitor message

2019-12-30 Thread Xiaojian Zhou (Jira)
Xiaojian Zhou created GEODE-7631:


 Summary: It's better to change the stuck to running in 
ThreadsMonitor message
 Key: GEODE-7631
 URL: https://issues.apache.org/jira/browse/GEODE-7631
 Project: Geode
  Issue Type: Bug
Reporter: Xiaojian Zhou


We found following warning message:

bridgegemfire2_15991/system.log:[warn 2019/12/17 23:53:09.074 PST 
 tid=0x29] Thread <1304> (0x518) that was executed at <17 Dec 
2019 23:52:28 PST> has been stuck for <40.628 seconds> and number of thread 
monitor iteration <1>

This "stuck" term confused us for a while. And we found actually the thread is 
still running normally. It just stay in run mode for too long (the limit to 
trigger the warning msg is 30 seconds). 

It's better to change the word "stuck" into "running" in order not to confuse 
customer. 




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


[jira] [Closed] (GEODE-7196) Simplify ClusterDistributionManager

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7196.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Simplify ClusterDistributionManager
> ---
>
> Key: GEODE-7196
> URL: https://issues.apache.org/jira/browse/GEODE-7196
> Project: Geode
>  Issue Type: Improvement
>  Components: membership
>Reporter: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> ClusterDistributionManager maintains its own idea of cluster membership apart 
> from the membership manager.  It also holds Executors for processing 
> messages.  Let's get rid of the membership management and move the executors 
> some-place else.



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


[jira] [Closed] (GEODE-7072) CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo > EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7072.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI Failure: WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo > 
> EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED
> 
>
> Key: GEODE-7072
> URL: https://issues.apache.org/jira/browse/GEODE-7072
> Project: Geode
>  Issue Type: Test
>  Components: wan
>Reporter: Owen Nichols
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo
>  > EventProcessingMixedSiteOneCurrentSiteTwo[from_v130] FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo$$Lambda$47/1509632157.run
>  in VM 0 running on Host aac3b458d9ea with 7 VMs with version 130
> 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.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.EventProcessingMixedSiteOneCurrentSiteTwo(WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.java:63)
> Caused by:
> org.apache.geode.InternalGemFireException: Unable to recover previous 
> membership view from locator26547view.dat
> at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recoverFromFile(GMSLocator.java:462)
> at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recover(GMSLocator.java:387)
> at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.init(GMSLocator.java:146)
> at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.init(InternalLocator.java:1225)
> at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:232)
> at 
> org.apache.geode.distributed.internal.InternalLocator.startTcpServer(InternalLocator.java:517)
> at 
> org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:575)
> at 
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:321)
> at 
> org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at 
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:105)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:97)
> at 
> org.apache.geode.cache.wan.WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.lambda$EventProcessingMixedSiteOneCurrentSiteTwo$6f8ee815$1(WANRollingUpgradeEventProcessingMixedSiteOneCurrentSiteTwo.java:63)
> Caused by:
> org.apache.geode.SerializationException: Could not create an 
> instance of  org.apache.geode.distributed.internal.membership.NetView .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:986)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at 
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.recoverFromFile(GMSLocator.java:440)
> ... 12 more
> Caused by:
> org.apache.geode.SerializationException: Could not create an 
> instance of  org.apache.geode.distributed.internal.membership.gms.GMSMember .
> at 
> org.apache.geode.internal.InternalDataSerializer.invokeFromData(InternalDataSerializer.java:2381)
> at 
> org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:986)
> at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2693)
> at 
> org.apache.geode.DataSerializer.readObject(DataSerializer.java:2961)
> at 
> org.apache.geode.distributed.internal.membership.NetView.fromData(NetView.java:603)
> at 
> org.apache.geode

[jira] [Closed] (GEODE-7531) PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances are PoolImpls

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7531.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> PoolManagerImpl.unregister(:Pool) naively assumes all Pool object instances 
> are PoolImpls
> -
>
> Key: GEODE-7531
> URL: https://issues.apache.org/jira/browse/GEODE-7531
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Affects Versions: 1.10.0
> Environment: Apache Geode based applications on the JVM.
>Reporter: John Blum
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> A recent 
> [change|https://github.com/apache/geode/blob/rel/v1.10.0/geode-core/src/main/java/org/apache/geode/internal/cache/PoolManagerImpl.java#L169-L174]
>  to the {{o.a.g.internal.cache.PoolManagerImpl}} class expects all 
> {{o.a.g.cache.client.Pools}} registered with the 
> {{o.a.g.cache.client.PoolManager}} to be 
> {{o.a.g.cache.client.internal.PoolImp}} objects.
> This is certainly not going to be the case for Unit Tests that properly 
> "mock" 1 or more {{Pool}} instances and additionally needs to register the 
> mock {{Pool}} instances with the {{PoolManager}}.  While the later may not be 
> as common for application code, it is more certainly common, and in some 
> cases necessary, for framework or tooling code.



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


[jira] [Closed] (GEODE-7042) Wait until all startup tasks complete to update server status as "online"

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7042.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Wait until all startup tasks complete to update server status as "online"
> -
>
> Key: GEODE-7042
> URL: https://issues.apache.org/jira/browse/GEODE-7042
> Project: Geode
>  Issue Type: Improvement
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
>  Labels: observability
> Fix For: 1.11.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Currently, the server status is set to "online" before all of the startup 
> tasks have completed. This tells users incorrect facts about the system and 
> its availability.
> *Scenario:*
>  Given a server has just been started
>  When the following threads have completed:
>      [Async] [Optional] Begin redundancy recovery
>      [Async] [Optional] Begin recovery of values from disk 
>  And when the synchronous thread of .start() for the ServerLauncher that 
> started the server completes without exception
>  Then the 'status' bit of the ServerLauncher should be set to 'online' 
> (currently this is set to online regardless of Async processes)
> *Notes:*
>  GFSH utilizes this 'online' status to return from the 'start server' command.



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


[jira] [Closed] (GEODE-7104) Ensure compatibility with Spring 5.x

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7104.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Ensure compatibility with Spring 5.x
> 
>
> Key: GEODE-7104
> URL: https://issues.apache.org/jira/browse/GEODE-7104
> Project: Geode
>  Issue Type: Improvement
>  Components: pulse
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Prior testing with Spring 5.x highlighted one minor issue with Pulse 
> authentication. The fix is backwards compatible with Spring 4.x.



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


[jira] [Closed] (GEODE-7134) Reduce overhead of PartitionedRegion.executeOnBucketSet

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7134.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Reduce overhead of PartitionedRegion.executeOnBucketSet
> ---
>
> Key: GEODE-7134
> URL: https://issues.apache.org/jira/browse/GEODE-7134
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, regions
>Reporter: Jacob Barrett
>Assignee: Mario Ivanac
>Priority: Major
>  Labels: needs-review, performance, pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 4h 10m
>  Remaining Estimate: 0h
>
> {{PartitionedRegion.executeOnBucketSet}} spends 56% of function executions 
> CPU time comparing and pruning bucket sets. It also accounts for 89% of the 
> transient object allocation during function execution.
> Given that bucket sets are sets of integers let's look for a more suitable 
> implementation of set operations on integers. Consider {{int[]}} as set of 
> integers too reduce CPU and transient object allocations.



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


[jira] [Closed] (GEODE-7286) When a durable client is killed for the second time, its socket is not closed properly

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7286.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> When a durable client is killed for the second time, its socket is not closed 
> properly
> --
>
> Key: GEODE-7286
> URL: https://issues.apache.org/jira/browse/GEODE-7286
> Project: Geode
>  Issue Type: Bug
>  Components: client queues
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The first time the durable client is killed, the socket is closed by 
> SocketCloser.inlineClose:
> {noformat}
> [warn 2019/10/10 12:26:07.025 PDT  
> tid=0x41] ClientHealthMonitor: Unregistering client with member id 
> identity(192.168.1.4(client:17910:loner):49501:cf8f22b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]) due to: The connection has been reset while reading the header
> [warn 2019/10/10 12:26:07.026 PDT  
> tid=0x41] XXX CacheClientProxy.closeSocket 
> socket=Socket[addr=/192.168.1.4,port=49506,localport=49494]; 
> socketIsClosed=false; _socketClosed=false
> [warn 2019/10/10 12:26:07.026 PDT  
> tid=0x41] XXX SocketCloser.asyncClose 
> socket=Socket[addr=/192.168.1.4,port=49506,localport=49494]; 
> socketIsClosed=false
> [info 2019/10/10 12:26:07.028 PDT  192.168.1.4(client:17910:loner):49501:cf8f22b7:client (client-1)> tid=0x42] 
> CacheClientProxy[identity(192.168.1.4(client:17910:loner):49501:cf8f22b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]); port=49506; primary=true; version=GEODE 1.11.0] : Pausing 
> processing
> [warn 2019/10/10 12:26:07.031 PDT  
> tid=0x46] XXX SocketCloser.inlineClose closed 
> socket=Socket[addr=/192.168.1.4,port=49506,localport=49494]; 
> socketIsClosed=true
> [info 2019/10/10 12:26:07.031 PDT  
> tid=0x41] CacheClientNotifier: Keeping proxy for durable client named 
> client-1 for 120 seconds 
> CacheClientProxy[identity(192.168.1.4(client:17910:loner):49501:cf8f22b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]); port=49506; primary=true; version=GEODE 1.11.0].
> {noformat}
> If the client rejoins and is killed again, the socket is not closed because 
> the _socketClosed AtomicBoolean is true from the last time the client closed, 
> so SocketCloser.asyncClose is not called:
> {noformat}
> [warn 2019/10/10 12:26:27.706 PDT  
> tid=0x4a] ClientHealthMonitor: Unregistering client with member id 
> identity(192.168.1.4(client:17939:loner):49519:62f822b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]) due to: The connection has been reset while reading the header
> [warn 2019/10/10 12:26:27.706 PDT  
> tid=0x4a] XXX CacheClientProxy.closeSocket 
> socket=Socket[addr=/192.168.1.4,port=49524,localport=49494]; 
> socketIsClosed=false; _socketClosed=true
> [info 2019/10/10 12:26:27.706 PDT  
> tid=0x4a] CacheClientNotifier: Keeping proxy for durable client named 
> client-1 for 120 seconds 
> CacheClientProxy[identity(192.168.1.4(client:17939:loner):49519:62f822b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]); port=49524; primary=true; version=GEODE 1.11.0].
> {noformat}
> Even when the durable client's expiration task fires, the socket is not 
> closed:
> {noformat}
> [warn 2019/10/10 12:28:27.708 PDT  tid=0x29] 
> CacheClientProxy[identity(192.168.1.4(client:17939:loner):49519:62f822b7:client,connection=2,durableAttributes=DurableClientAttributes[id=client-1;
>  timeout=120]); port=49524; primary=true; version=GEODE 1.11.0] : The 
> expiration task has fired, so this proxy is being terminated.
> [warn 2019/10/10 12:28:27.710 PDT  tid=0x29] XXX 
> CacheClientProxy.closeSocket 
> socket=Socket[addr=/192.168.1.4,port=49524,localport=49494]; 
> socketIsClosed=false; _socketClosed=true
> [warn 2019/10/10 12:28:27.712 PDT  tid=0x29] XXX 
> CacheClientProxy.closeSocket 
> socket=Socket[addr=/192.168.1.4,port=49524,localport=49494]; 
> socketIsClosed=false; _socketClosed=true
> {noformat}
> The AtomicBoolean needs to be reset when the durable client rejoins.



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


[jira] [Closed] (GEODE-7350) LogConsumer MALFORMED_LOG4J_MESSAGE matches hydra.MasterDescription.master.locators={}

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7350.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> LogConsumer MALFORMED_LOG4J_MESSAGE matches 
> hydra.MasterDescription.master.locators={}
> --
>
> Key: GEODE-7350
> URL: https://issues.apache.org/jira/browse/GEODE-7350
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> LogConsumer MALFORMED_LOG4J_MESSAGE matches:
> {noformat}
> hydra.MasterDescription.master.locators={}
> {noformat}
> which causes false positives when grepping for log output for malformed log4j 
> messages.
> LogConsumer needs to be adjusted to ignore {} when it comes after 
> {{hydra.MasterDescription.master.locators=}}.



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


[jira] [Commented] (GEODE-7345) Break dependency on Tcp socket related classes

2019-12-30 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-7345:


Commit 30797a1f99540635812e7bca2d5b5d7da6d8bd8b in geode's branch 
refs/heads/develop from Ernie Burghardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=30797a1 ]

GEODE-7345: Clean up resolved dependency exceptions in ArchUnit tests. (#4536)




> Break dependency on Tcp socket related classes
> --
>
> Key: GEODE-7345
> URL: https://issues.apache.org/jira/browse/GEODE-7345
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> CommunicationMode
> SocketCreator
> SSLConfigurationFactory
> SecurableCommunicationChannel
> SocketCreatorFactory.
> SSLConfigurationFactor



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


[jira] [Closed] (GEODE-6915) Improve CompiledGroupBySelect Integration Test

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6915.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Improve CompiledGroupBySelect Integration Test
> --
>
> Key: GEODE-6915
> URL: https://issues.apache.org/jira/browse/GEODE-6915
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The name for {{CompiledGroupBySelectJUnitTest}} implies that the test is a 
> *unit test* but it's not, it's actually an *integration test*: rename the 
> class to {{CompiledGroupBySelectIntegrationTest}} instead. Also, the test 
> only verifies the query compilation for some variations only ({{count}}, 
> {{group by}} and {{max}}), add tests for the remaining aggregate functions.



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


[jira] [Closed] (GEODE-7296) Fix Geode release scripts

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7296.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Fix Geode release scripts
> -
>
> Key: GEODE-7296
> URL: https://issues.apache.org/jira/browse/GEODE-7296
> Project: Geode
>  Issue Type: Bug
>  Components: release
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Minor bug fixes



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


[jira] [Closed] (GEODE-7118) RestartOfMemberDistributedTest fails intermittently in precheckin

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7118.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> RestartOfMemberDistributedTest fails intermittently in precheckin
> -
>
> Key: GEODE-7118
> URL: https://issues.apache.org/jira/browse/GEODE-7118
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This has failed in two PR precheckins yesterday (August 23):
> * 
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-3914/test-results/distributedTest/1566513976/
> * 2nd failed rsync during archiving
> In both precheckins, RestartOfMemberDistributedTest was the only dunit to 
> fail.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.rules.MemberVM$$Lambda$165/0x000840a8e440.run 
> in VM 2 running on Host ecb3754c4d31 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.dunit.rules.MemberVM.waitTilFullyReconnected(MemberVM.java:133)
>   at 
> org.apache.geode.distributed.internal.RestartOfMemberDistributedTest.exCoordinatorJoiningQuorumDoesNotThrowNullPointerException(RestartOfMemberDistributedTest.java:79)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at 
> org.apache.geode.test.dunit.rules.ClusterStartupRule$1.evaluate(ClusterStartupRule.java:146)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
>   at 
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:566)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$

[jira] [Closed] (GEODE-7240) Prevent Usage of Aggregates within WHERE clause

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7240.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Prevent Usage of Aggregates within WHERE clause
> ---
>
> Key: GEODE-7240
> URL: https://issues.apache.org/jira/browse/GEODE-7240
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Aggregate functions shouldn't be allowed as part of the {{WHERE}} clause.
> Currently, instead of rejecting the query, we throw a {{ClassCastException}} 
> while trying to evaluate the condition:
> {noformat}
> org.apache.geode.cache.query.TypeMismatchException: Unable to use a 
> relational comparison operator to compare an instance of class ' 
> org.apache.geode.cache.query.internal.aggregate.XXX ' with an instance of ' 
> java.lang.XXX '
>   at 
> org.apache.geode.cache.query.internal.types.TypeUtils$ComparisonStrategy.get(TypeUtils.java:144)
>   at 
> org.apache.geode.cache.query.internal.types.TypeUtils.compare(TypeUtils.java:499)
>   at 
> org.apache.geode.cache.query.internal.CompiledComparison.evaluate(CompiledComparison.java:137)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:438)
>   at 
> org.apache.geode.cache.query.internal.CompiledSelect.evaluate(CompiledSelect.java:53)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.executeUsingContext(DefaultQuery.java:432)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:267)
>   at 
> org.apache.geode.cache.query.internal.DefaultQuery.execute(DefaultQuery.java:199)
> {noformat}



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


[jira] [Closed] (GEODE-7426) Integration tests segfault on MacOs with geode-native

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7426.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Integration tests segfault on MacOs with geode-native
> -
>
> Key: GEODE-7426
> URL: https://issues.apache.org/jira/browse/GEODE-7426
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> A segfault occurs on MacOS when running any of the integration tests.
>  



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


[jira] [Closed] (GEODE-7277) CI failure: DestroyLuceneIndexCommandsDUnitTest > testDestroyIndexesWithOneIndexAndRegionInOneMember failed with RegionDestroyedException suspicious string

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7277.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI failure: DestroyLuceneIndexCommandsDUnitTest > 
> testDestroyIndexesWithOneIndexAndRegionInOneMember failed with 
> RegionDestroyedException suspicious string
> ---
>
> Key: GEODE-7277
> URL: https://issues.apache.org/jira/browse/GEODE-7277
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Barrett Oglesby
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DistributedTestOpenJDK11 #1147 
> (https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1147)
>  failed with this RegionDestroyedException suspicious string:
> {noformat}
> org.apache.geode.cache.lucene.internal.cli.DestroyLuceneIndexCommandsDUnitTest
>  > testDestroyIndexesWithOneIndexAndRegionInOneMember 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 2012
> [fatal 2019/10/07 21:18:02.334 GMT  tid=845] Uncaught 
> exception in thread Thread[FederatingManager4,5,RMI Runtime]
> org.apache.geode.cache.RegionDestroyedException: 
> org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_172.17.0.1041002';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE]
>   at 
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128)
>   at 
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:452)
>   at 
> org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
>   at 
> org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67)
>   at 
> org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> This failure has nothing to do with Lucene.
> Some analysis shows that stopping a member and stopping the locator nearly 
> simultaneously can cause this RegionDestroyedException.
> The test output shows:
> The locator starts:
> {noformat}
> [vm0] [info 2019/10/07 21:17:55.174 GMT  
> tid=0x22] Starting DistributionManager 
> 172.17.0.10(locator-0:87:locator):41000.  (took 26 ms)
> {noformat}
> Server1 starts and _monitoringRegion_172.17.0.1041001 is created for it 
> in the locator:
> {noformat}
> [vm1] [info 2019/10/07 21:17:59.681 GMT  
> tid=0x22] Starting DistributionManager 172.17.0.10(server-1:95):41001.  
> (took 405 ms)
> [vm0] [info 2019/10/07 21:17:59.684 GMT  tid=0x332] 
> Initializing region _monitoringRegion_172.17.0.1041001
> [vm0] [info 2019/10/07 21:17:59.694 GMT  tid=0x332] 
> Initialization of region _monitoringRegion_172.17.0.1041001 completed
> {noformat}
> Server2 starts and _monitoringRegion_172.17.0.1041002 is created for it 
> in the locator:
> {noformat}
> [vm2] [info 2019/10/07 21:18:00.379 GMT  
> tid=0x22] Starting DistributionManager 172.17.0.10(server-2:104):41002.  
> (took 361 ms)
> [vm0] [info 2019/10/07 21:18:00.379 GMT  tid=0x33c] 
> Initializing region _monitoringRegion_172.17.0.1041002
> [vm0] [info 2019/10/07 21:18:00.424 GMT  tid=0x33c] 
> Initialization of region _monitoringRegion_172.17.0.1041002 completed
> {noformat}
> Server2 shuts down:
> {noformat}
> [vm2] [info 2019/10/07 21:18:02.007 GMT  
> tid=0x22] Shutting down DistributionManager 
> 172.17.0.10(server-2:104):41002. 
> [vm2] [info 2019/10/07 21:18:02.127 GMT  
> tid=0x22] Marking DistributionManager 172.17.0.10(server-2:104):41002 as 
> closed.
> {noformat}
> Server1 shuts down:
> {noformat}
> [vm1] [info 2019/10/07 21:18:02.189 GMT  
> tid=0x22] Shuttin

[jira] [Closed] (GEODE-7392) Add tag indicating the commit under test to heavy lifters

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7392.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Add tag indicating the commit under test to heavy lifters
> -
>
> Key: GEODE-7392
> URL: https://issues.apache.org/jira/browse/GEODE-7392
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Sean Goller
>Assignee: Sean Goller
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Currently heavy lifter instances are tagged with information about the build 
> in concourse it was launched by. In order to facilitate forensics from 
> metrics, tag the instance with the commit under test.



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


[jira] [Closed] (GEODE-7103) CI Failure: org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest test000PartitionedRegionCreate hang

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7103.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI Failure: 
> org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest 
> test000PartitionedRegionCreate hang
> --
>
> Key: GEODE-7103
> URL: https://issues.apache.org/jira/browse/GEODE-7103
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This test hung in an integration-test pipeline task.  The test has a lot of 
> while-loops that have no timeouts.  Since the run timed out we have no good 
> artifacts.
>  
> {noformat}
> "Test worker" #27 prio=5 os_prio=0 cpu=3696.49ms elapsed=1187.94s 
> tid=0x7fa200af8800 nid=0x1a in Object.wait()  [0x7fa1d012c000]"Test 
> worker" #27 prio=5 os_prio=0 cpu=3696.49ms elapsed=1187.94s 
> tid=0x7fa200af8800 nid=0x1a in Object.wait()  [0x7fa1d012c000]   
> java.lang.Thread.State: WAITING (on object monitor) at 
> java.lang.Object.wait(java.base@11.0.4/Native Method) - waiting on 
> <0xd0570f78> (a java.lang.Object) at 
> java.lang.Object.wait(java.base@11.0.4/Object.java:328) at 
> org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest.createMultiplePartitionedRegions(PartitionedRegionCreationJUnitTest.java:402)
>  - waiting to re-lock in wait() <0xd0570f78> (a java.lang.Object) at 
> org.apache.geode.internal.cache.PartitionedRegionCreationJUnitTest.test000PartitionedRegionCreate(PartitionedRegionCreationJUnitTest.java:109)
>  {noformat}



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


[jira] [Closed] (GEODE-2888) user guide: REST API Region Endpoints use 'gemfire-api' in their names

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-2888.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> user guide: REST API Region Endpoints use  'gemfire-api' in their names
> ---
>
> Key: GEODE-2888
> URL: https://issues.apache.org/jira/browse/GEODE-2888
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> The name 'gemfire-api' should be replaced by 'geode' in the Region Endpoints 
> section of the manual. See 
> http://geode.apache.org/docs/guide/11/rest_apps/rest_regions.html and its 
> subsections.



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


[jira] [Closed] (GEODE-7319) BucketRegionTest > invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized FAILED

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7319.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> BucketRegionTest > 
> invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized
>  FAILED
> -
>
> Key: GEODE-7319
> URL: https://issues.apache.org/jira/browse/GEODE-7319
> Project: Geode
>  Issue Type: Bug
>  Components: ci
>Reporter: Mario Ivanac
>Assignee: Mario Ivanac
>Priority: Major
>  Labels: flaky, needs-review, pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
>  
>  
> org.apache.geode.internal.cache.BucketRegionTest > 
> invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized
>  FAILED
>  
>  java.lang.NullPointerException
>  
>  at 
> org.apache.geode.internal.cache.EntryEventImpl.(EntryEventImpl.java:343)
>  
>  at 
> org.apache.geode.internal.cache.EntryEventImpl.(EntryEventImpl.java:314)
>  
>  at 
> org.apache.geode.internal.cache.BucketRegion.createEventForPR(BucketRegion.java:1613)
>  
>  at 
> org.apache.geode.internal.cache.BucketRegion.invokeDestroyCallbacks(BucketRegion.java:1706)
>  
>  at 
> org.apache.geode.internal.cache.BucketRegionTest.invokeDestroyCallbacksDoesNotInvokeCallbacksIfPartitionedRegionIsNotInitialized(BucketRegionTest.java:459)



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


[jira] [Closed] (GEODE-7064) Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in Concourse

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7064.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Increase timeout from 10 to 20 minutes on UnitTestX execute_test task in 
> Concourse
> --
>
> Key: GEODE-7064
> URL: https://issues.apache.org/jira/browse/GEODE-7064
> Project: Geode
>  Issue Type: Improvement
>  Components: ci
>Reporter: Ryan McMahon
>Assignee: Ryan McMahon
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We have seen several timeouts in the execute_test task in UnitTestX jobs in 
> the CI which were found to be resolved by experimenting with increasing the 
> timeout.  The community agreed we should increase the timeout from 10 to 20 
> minutes to handle intermittent degradation of the performance of this task, 
> due to infrastructure issues or otherwise.



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


[jira] [Closed] (GEODE-6973) getExistingIdForType should not compare all entries in idToType region

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6973.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> getExistingIdForType should not compare all entries in idToType region
> --
>
> Key: GEODE-6973
> URL: https://issues.apache.org/jira/browse/GEODE-6973
> Project: Geode
>  Issue Type: Bug
>Reporter: Xiaojian Zhou
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 8h
>  Remaining Estimate: 0h
>
> We found the PeerTypeRegistration's getExistingIdForType() will iterate 
> through the idToType region's entries to find if the incoming newType is 
> there. 
> If idToType region contains 20K or 100K entries, this will impact the put 
> throughput (customers did notice the performance downgrade when there're many 
> pdxTypes). 
> To make the things worse, the comparison is to compare the whole object, 
> field to field. If the json object (which will be converted to pdxType) 
> contains 30 fields, the comparison will have to compare up to 30 fields. If 
> the idToType region contains 20K entries, A new pdxType will do 20K  x 30 
> string comparisons before register it. 
> We found each server maintained a typeToId map, this map is used to check if 
> the pdxType exists. If exists, it will return the type id without check the 
> IdToType region. The total number of pdxType did not impact the put 
> performance if the pdxTypd exists. 
> The typeToId map is maintained with a d-lock, each time we added a new 
> pdxType, it will update into the map while still holding the d-lok. So we 
> believe that the map should be the same as the region in content. If we 
> cannot find the pdxType in the map, it should not be in the region. We can 
> skip the iteration of region (which is the root cause of the performance 
> issue). 
> Another issue in current code is: when each time a new type come, it will 
> recreate the map. This is unnecessary and contributes to the slowness too. 
> We should only create the map during initialize(). 
> Here are the tests we want to introduce:
> 1) a junit test to prove that reorder fields in a big JSON file will not 
> cause significant hashcode conflicts (<1%)
> 2) a junit test to prove that add a index to a field in a big JSON file will 
> hardly cause hashcode conflicts. 
> This 2 tests are to prove that hashcode conflict is not the root cause of 
> linear probing for PDXTypeId. 
> 3) a junit test to prove that for the cases that hashcode conflict caused by 
> reordered fields, there will be no hashcode conflicts if using 
> SORT_JSON_FIELD_NAMES_PROPERTY=true. 
> 4) a dunit test to prove that SORT_JSON_FIELD_NAMES_PROPERTY=true or false 
> did not impact the performance to add a new pdxType. 
> 5) a dunit test to create a new pdxType from 2 peer server at the same time. 
> The test is to prove that the d-lock take effect, one server create the 
> pdxType, and another server should find the pdxType exists. 
> Do this test both from server directly and from clients. 
> 6) Create 2 different objects which ends up with the same hashcode (we can 
> get the 2 objects from test-1), try to put the 2 objects to create new 
> pdxType. The 2nd one should also create a new type. It should not be treated 
> as "found an existing pdxType". 



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


[jira] [Closed] (GEODE-6906) Review OQL Aggregate Functions

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6906.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Review OQL Aggregate Functions
> --
>
> Key: GEODE-6906
> URL: https://issues.apache.org/jira/browse/GEODE-6906
> Project: Geode
>  Issue Type: Improvement
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>
> Top level ticket to aggregate all tasks required to improve the documentation 
> and test coverage for [OQL Aggregate 
> Functions|https://geode.apache.org/docs/guide/19/developing/query_select/aggregates.html].



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


[jira] [Closed] (GEODE-7332) Add OQL Aggregates link in docs

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7332.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Add OQL Aggregates link in docs
> ---
>
> Key: GEODE-7332
> URL: https://issues.apache.org/jira/browse/GEODE-7332
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Small change, but useful. File 
> developing/querying_basics/what_is_a_query_string.html has a list of useful 
> query string building blocks.  Add a link to the descriptions of the OQL 
> aggregates to the list.



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


[jira] [Closed] (GEODE-7071) Add CA capability to CertStores

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7071.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Add CA capability to CertStores
> ---
>
> Key: GEODE-7071
> URL: https://issues.apache.org/jira/browse/GEODE-7071
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Most (all?) SSL tests end up using self-signed certificates. We should add an 
> actual root CA so that certificates can actually be signed correctly.



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


[jira] [Closed] (GEODE-6987) Implement RegExMethodAuthorizer

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6987.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Implement RegExMethodAuthorizer
> ---
>
> Key: GEODE-6987
> URL: https://issues.apache.org/jira/browse/GEODE-6987
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Implement the [RegExMethodAuthorizer 
> |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RegExMethodAuthorizer]
>  class.
> * Make sure the class is immutable and thread safe.
> * Implement unit tests for the class and all of its methods.
> * Add comprehensive  and clear documentation to the class and all its public 
> methods so customers can use it without leaving their IDE.



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


[jira] [Commented] (GEODE-7626) Break dependency on LocalViewMessage in membership

2019-12-30 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-7626:


Commit 10d1b8c4d5de036e773a377b7282c5581514a239 in geode's branch 
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10d1b8c ]

GEODE-7626: Break dependency on LocalViewMessage in membership (#4538)

* GEODE-7626: Break dependency on LocalViewMessage in membership

LocalViewMessage was a DistributionMessage executed in an executor owned
by ClusterDistributionmanager.  This arrangement was very convoluted
because CDM only had upstream involvement in membership view
installation.

This PR moves view installation into GMSMembership using a
single-threaded executor similar to what CDM used but without
statistics.  Stats for the view installation thread have never been
useful so I have not retained that functionality.

There are already many tests for view installation, so while I've
modified a couple I haven't added any new tests.

* make constructor private

* simplifying the executor


> Break dependency on LocalViewMessage in membership
> --
>
> Key: GEODE-7626
> URL: https://issues.apache.org/jira/browse/GEODE-7626
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Dan Smith
>Assignee: Bruce J Schuchardt
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7369) Deprecate SystemFailure Class

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7369.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Deprecate SystemFailure Class
> -
>
> Key: GEODE-7369
> URL: https://issues.apache.org/jira/browse/GEODE-7369
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The {{SystemFailure}} class is a clearing house for detecting and attempting 
> to mitigate {{SystemFailure}} exceptions e.g. {{VirtualMachineError}} and 
> {{OutOfMemoryError}}.
> This class should not exist. {{SystemFailure}} exceptions should be allowed 
> to percolate up and cause the JVM to terminate as soon as possible with an 
> informative message in the log, if possible.
> Here is what the JVM spec has to say [1]:
> "A Java Virtual Machine implementation throws an object that is an instance 
> of a subclass of the class VirtualMethodError (sic) when an internal error or 
> resource limitation prevents it from implementing the semantics described in 
> this chapter. This specification cannot predict where internal errors or 
> resource limitations may be encountered and does not mandate precisely when 
> they can be reported."
> There's a typo in the spec there: it says "VirtualMethodError" when it means 
> "VirtualMachineError". Anyhoo, the upshot is: the JVM spec does not apply 
> after you've encountered a {{VirtualMachineError}}. As a result, there is no 
> reason to believe that subsequent processing will make things _better_ (than 
> exiting immediately).
> The SystemFailure class should be deprecated so no new dependencies to it are 
> added. Existing dependencies on it, should be eliminated over time.
> This ticket was discussed on the Apache Geode dev list and "rough consensus" 
> was achieved[2]
> [1] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.3
> [2] 
> https://lists.apache.org/thread.html/61a1fbeda2c29f83e695f9e20512c15ab6db8a4c91990352a41f7dfb@%3Cdev.geode.apache.org%3E



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


[jira] [Closed] (GEODE-7346) Break dependency on client protocol service

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7346.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Break dependency on client protocol service
> ---
>
> Key: GEODE-7346
> URL: https://issues.apache.org/jira/browse/GEODE-7346
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Ernest Burghardt
>Priority: Major
> Fix For: 1.11.0
>
>
> ClientProtocolServiceLoader
> ClientProtocolService
> ClientProtocolProcessor



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


[jira] [Resolved] (GEODE-7626) Break dependency on LocalViewMessage in membership

2019-12-30 Thread Bruce J Schuchardt (Jira)


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

Bruce J Schuchardt resolved GEODE-7626.
---
Fix Version/s: 1.12.0
   Resolution: Fixed

> Break dependency on LocalViewMessage in membership
> --
>
> Key: GEODE-7626
> URL: https://issues.apache.org/jira/browse/GEODE-7626
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Dan Smith
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7322) generate wiki page of Cluster Management Service from Swagger page

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7322.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> generate wiki page of Cluster Management Service from Swagger page
> --
>
> Key: GEODE-7322
> URL: https://issues.apache.org/jira/browse/GEODE-7322
> Project: Geode
>  Issue Type: Bug
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Owen Nichols
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> #WHY
> we want to get the latest update of restapi, and update wiki page 
> automatically
> #WHAT
> find a programming way to update wiki page
> And sync the latest update of Swagger to wiki
> related:
> GEODE-7205 : https://issues.apache.org/jira/browse/GEODE-7205



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


[jira] [Closed] (GEODE-5940) ServerLauncherRemoteIntegrationTest times out waiting for server to start

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-5940.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> ServerLauncherRemoteIntegrationTest times out waiting for server to start
> -
>
> Key: GEODE-5940
> URL: https://issues.apache.org/jira/browse/GEODE-5940
> Project: Geode
>  Issue Type: Test
>Reporter: Dale Emery
>Assignee: Kirk Lund
>Priority: Major
>  Labels: swat
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.8.0-build.50/test-results/integrationTest/1540492907/classes/org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.html#startOverwritesStalePidFile
> {noformat}
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined as 
> a lambda expression in 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that 
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but 
> was:<[not responding]> 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:890)
>   at 
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:711)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:200)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:178)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:189)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:128)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:124)
>   at 
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.startOverwritesStalePidFile(ServerLauncherRemoteIntegrationTest.java:91)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.Verifier$1.evaluate(Verifier.java:35)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:106)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
>   at 
> org.gradle.api.

[jira] [Closed] (GEODE-6984) Publish MethodInvocationAuthorizer and RestrictedMethodInvocationAuthorizer

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6984.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Publish MethodInvocationAuthorizer and RestrictedMethodInvocationAuthorizer
> ---
>
> Key: GEODE-6984
> URL: https://issues.apache.org/jira/browse/GEODE-6984
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Move both classes out of the {{internal}} package and make them public. The 
> new name for {{RestrictedMethodInvocationAuthorizer}} should be 
> {{RestrictedMethodAuthorizer}}.
>  Once this ticket is implemented, the {{DefaultQueryService}} should use the 
> actual rules and 
> [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 new {{RestrictedMethodAuthorizer}} by default so we can continue 
> implementing the rest of the proposal without blocking any releases.
> Add comprehensive and clear documentation to the classes and all methods so 
> customers can use and understand them without leaving their IDE.



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


[jira] [Closed] (GEODE-7357) membership-timeout documentation is incorrect

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7357.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> membership-timeout documentation is incorrect
> -
>
> Key: GEODE-7357
> URL: https://issues.apache.org/jira/browse/GEODE-7357
> Project: Geode
>  Issue Type: Bug
>  Components: docs, membership
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The description for membership-timeout on 
> https://geode.apache.org/docs/guide/110/reference/topics/gemfire_properties.html
>  is incorrect.
> It describes the member-timeout behavior of an old version of the product, 
> before geode 1.0. 
> Based on this description, a user might assume that an unresponsive member 
> will be kicked out of the system only after 3*member-timeout milliseconds 
> have elapsed. That may have been true before geode 1.0, but the geode has a 
> different failure detection algorithm which will remove members after a 
> minimum of 2*member-timeout milliseconds



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


[jira] [Closed] (GEODE-7272) Docker image to build and preview the user guide

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7272.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Docker image to build and preview the user guide
> 
>
> Key: GEODE-7272
> URL: https://issues.apache.org/jira/browse/GEODE-7272
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Alberto Bustamante Reyes
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> For building the Geode user guide it is needed to install Ruby and 
> Bookbinder. It would be useful to have a docker image to do this task.



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


[jira] [Closed] (GEODE-7288) LuceneIntegrationTest uses non-existent system property logLevel

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7288.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> LuceneIntegrationTest uses non-existent system property logLevel
> 
>
> Key: GEODE-7288
> URL: https://issues.apache.org/jira/browse/GEODE-7288
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> DUnit ProcessManager used to set the system property {{logLevel}} but this 
> was changed to {{gemfire.log-level}} in 2016. The only uses of {{logLevel}} 
> were:
> * 
> geode-core/src/distributedTest/java/org/apache/geode/distributed/internal/LDM 
> (which is an unused class)
> * 
> geode-lucene-test/src/main/java/org/apache/geode/cache/lucene/LuceneIntegrationTest
>  (super class for other lucene tests)
> LuceneIntegrationTest:
> {noformat}
> cf.set(ConfigurationProperties.LOG_LEVEL, System.getProperty("logLevel", 
> "info"));
> {noformat}



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


[jira] [Closed] (GEODE-7102) Convert tests that use fixed key/trust stores to use CertificateBuilder

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7102.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Convert tests that use fixed key/trust stores to use CertificateBuilder
> ---
>
> Key: GEODE-7102
> URL: https://issues.apache.org/jira/browse/GEODE-7102
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> We now have the ability to create CAs and signed certificates in tests with a 
> simple java api. Convert all tests that reference key and truststore files to 
> use this java api - {{CertificateBuilder}} and {{CertStores}}.



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


[jira] [Closed] (GEODE-7077) POST pdx can not update the pdx config when a server is running

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7077.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> POST pdx can not update the pdx config when a server is running
> ---
>
> Key: GEODE-7077
> URL: https://issues.apache.org/jira/browse/GEODE-7077
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Gang Yan
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> For REST API V2 for management, 
> I had one locator and one server. I did a post pdx and it worked. I then 
> tried doing it again and it failed like so:
> 409 Error: Conflict
> {
> "statusCode": "ENTITY_EXISTS",
> "statusMessage": "Pdx 'PDX' already exists on member(s) server1."
> }
> Note that "409" is not documented in swagger.
> I would expect to be able to update the pdx config with the same type of 
> message I get on a create (that if a server is running it needs to be 
> restarted).
> If I stopped server1 then the POST worked with a 201:
> {
> "statusCode": "OK",
> "statusMessage": "Successfully updated configuration for cluster.",
> "uri": "/management/experimental/configurations/pdx"
> }
> I think POST pdx create and update should be consistent with each other. They 
> should both either force you to stop a running server before you can do the 
> op, or they should both support being done when a server is running.
> *TODO*
>  # update the method to be put from post, the response will be 200 when 
> everything runs well



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


[jira] [Closed] (GEODE-7132) Remove synchronized system property call in AbstractExecution constructor

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7132.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Remove synchronized system property call in AbstractExecution constructor
> -
>
> Key: GEODE-7132
> URL: https://issues.apache.org/jira/browse/GEODE-7132
> Project: Geode
>  Issue Type: Improvement
>  Components: functions
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>  Labels: performance
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> AbstractExecution gets a system property in the constructor which results in 
> synchronizing all construction of function executions. This high level of 
> monitor contention results in slowing throughput of functions.



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


[jira] [Closed] (GEODE-7400) Prevent RejectedExecutionException in FederatingManager

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7400.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Prevent RejectedExecutionException in FederatingManager
> ---
>
> Key: GEODE-7400
> URL: https://issues.apache.org/jira/browse/GEODE-7400
> Project: Geode
>  Issue Type: Bug
>Reporter: Aaron Lindsey
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.11.0, 1.12.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The fix for GEODE-7330 changed the {{FederatingManager}} class so that it 
> reuses the same {{ExecutorService}} between restarts. Now, if we start the 
> manager after previously starting and stopping it, we get 
> {{RejectedExecutionException}} because it tries to invoke a task on the same 
> {{ExecutorService}} which has been shut down.



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


[jira] [Closed] (GEODE-7363) Add member type the tags for meterics

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7363.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Add member type the tags for meterics
> -
>
> Key: GEODE-7363
> URL: https://issues.apache.org/jira/browse/GEODE-7363
> Project: Geode
>  Issue Type: New Feature
>  Components: statistics
>Reporter: Mark Hanson
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This would be good to tell the type of member that is providing the 
> information such as server, locator, embedded cache, or a server with an 
> embedded locator.



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


[jira] [Closed] (GEODE-6946) geode-managment should create its own set of configuration objects for GatewayReceiverConfiguration

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6946.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> geode-managment should create its own set of configuration objects for 
> GatewayReceiverConfiguration
> ---
>
> Key: GEODE-6946
> URL: https://issues.apache.org/jira/browse/GEODE-6946
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> GatewayReceiverConfig
> only add the supported attributes
> modify the implementation of ConfigurationManager to do the bridging between 
> the configuration objects and xml domain objects



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


[jira] [Closed] (GEODE-7341) Need to provide a way for user to avoid lock memory if not enough memory available

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7341.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Need to provide a way for user to avoid lock memory if not enough memory 
> available
> --
>
> Key: GEODE-7341
> URL: https://issues.apache.org/jira/browse/GEODE-7341
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Currently Geode supports ALLOW_MEMORY_OVERCOMMIT when encountering not enough 
> memory available during lock memory. 
> Geode should provide another way to avoid locking memory at all.



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


[jira] [Closed] (GEODE-7374) ResultModel cannot be cast to Result

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7374.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> ResultModel cannot be cast to Result
> 
>
> Key: GEODE-7374
> URL: https://issues.apache.org/jira/browse/GEODE-7374
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> a class cast failure when they use CommandService(like attached java class) 
> to run gfsh command such as list region:
> org.apache.geode.management.internal.cli.result.model.ResultModel cannot be 
> cast to org.ap



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


[jira] [Closed] (GEODE-7330) CI Failure: RebalanceCommandDUnitTest > testWithTimeOutAndRegion FAILED

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7330.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI Failure: RebalanceCommandDUnitTest > testWithTimeOutAndRegion FAILED
> ---
>
> Key: GEODE-7330
> URL: https://issues.apache.org/jira/browse/GEODE-7330
> Project: Geode
>  Issue Type: Test
>  Components: jmx
>Reporter: Ernest Burghardt
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
>  
> {code:java}
> org.apache.geode.management.internal.cli.commands.RebalanceCommandDUnitTest > 
> testWithTimeOutAndRegion 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 2985
> [fatal 2019/10/21 13:15:18.178 GMT  tid=716] Uncaught 
> exception in thread Thread[FederatingManager3,5,RMI Runtime]
> org.apache.geode.cache.RegionDestroyedException: 
> org.apache.geode.internal.cache.DistributedRegion[path='/_monitoringRegion_172.17.0.1841001';scope=DISTRIBUTED_NO_ACK';dataPolicy=REPLICATE]
>   at 
> org.apache.geode.internal.cache.LocalRegion.checkRegionDestroyed(LocalRegion.java:7293)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6157)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1821)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6128)
>   at 
> org.apache.geode.internal.cache.LocalRegion.localDestroyRegion(LocalRegion.java:2251)
>   at 
> org.apache.geode.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:453)
>   at 
> org.apache.geode.management.internal.FederatingManager.removeMemberArtifacts(FederatingManager.java:216)
>   at 
> org.apache.geode.management.internal.FederatingManager.access$000(FederatingManager.java:67)
>   at 
> org.apache.geode.management.internal.FederatingManager$RemoveMemberTask.run(FederatingManager.java:564)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {code}
>  
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1203
>  



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


[jira] [Closed] (GEODE-7283) OQL Method Authorizer in Query Execution Context

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7283.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> OQL Method Authorizer in Query Execution Context
> 
>
> Key: GEODE-7283
> URL: https://issues.apache.org/jira/browse/GEODE-7283
> Project: Geode
>  Issue Type: Improvement
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> When using security, the OQL method authorizer is instantiated multiple times 
> during the OQL execuion, incurring into a waste of time and resources.
>  The authorizer is obtained through the 
> {{queryContext.getCache().getQueryService().getMethodInvocationAuthorizer()}} 
> method, which basically creates a new instance of the {{DefaultQueryService}} 
> and, also, a new instance of the {{MethodInvocationAuthorizer}} configured:
> {code:java|title=DefaultQueryService.java|borderStyle=solid}
> public DefaultQueryService(InternalCache cache) {
>   if (cache == null)
>   throw new IllegalArgumentException("cache must not be null");
>   this.cache = cache;
>   if (!cache.getSecurityService().isIntegratedSecurity() || 
> ALLOW_UNTRUSTED_METHOD_INVOCATION) {
> // A no-op authorizer, allow method invocation
> this.methodInvocationAuthorizer = ((Method m, Object t) -> true);
>   } else {
> this.methodInvocationAuthorizer = new RestrictedMethodAuthorizer(cache);
>   }
> }
> {code}
> When using implicit method invocation, the above implies that the authorizer 
> will be created X times per query, being X the amount of attributes accessed 
> per object multiplied by the amount of objects traversed by the query. As an 
> example, if we have a region with 100 entries (entry has a non-public 
> {{name}} attribute with a public {{getName()}} accessor) and we execute 
> {{SELECT o.name FROM /Region o}}, the {{MethodInvocationAuthorizer}} will be 
> instantiated 100 times.
>  When using explicit method invocation things are "better": the 
> {{MethodInvocationAuthorizer}} is only created once for every new (unknown) 
> method during the lifetime of the Geode member, and that's basically because 
> the {{MethodDispatch}} class is internally cached and it also has the 
> {{MethodInvocationAuthorizer}} used when it was created stored internally. 
> This incurs into another problem: once a {{MethodDispatch}} is created, the 
> {{MethodInvocationAuthorizer}} can't be changed, the user needs to restart 
> the member in order to clear the cache ({{CompiledOperation}}) and force the 
> query engine to execute a new lookup of the now unknown method (which must 
> also be done through the API when implementing GEODE-6991, otherwise changes 
> won't be applied).
>  The {{MethodInvocationAuthorizer}} should be unique and unchangeable during 
> the execution of a particular query on a particular member, so we should 
> investigate whether it would make sense to create it only once at the 
> beginning of the query execution and have it directly available as part of 
> the {{QueryExecutionContext}}.



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


[jira] [Closed] (GEODE-6985) Implement RestrictedMethodAuthorizer

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6985.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Implement RestrictedMethodAuthorizer
> 
>
> Key: GEODE-6985
> URL: https://issues.apache.org/jira/browse/GEODE-6985
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Implement the 
> [RestrictedMethodAuthorizer|https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-RestrictedMethodAuthorizer]
>  class.
> * Make sure the class is immutable and thread safe.
> * Add two new public methods to the implementation:
> ** {{isAllowedGeodeMethod}}: it should return {{true}} when the {{Method}} on 
> the target {{Object}} is considered safe ({{Region.get}}, 
> {{Region.entrySet}}, {{Region.keySet}}, {{Region.values}}, 
> {{Region.getEntries}}, {{Region.getValues}}, {{Region.containsKey}}, 
> {{Region.getKey}} and {{Region.getValue}}), and {{false}} otherwise.
>  ** {{isKnownDangerousMethod}}: it should return {{true}} when the {{Method}} 
> on the target {{Object}} is known to be a non-safe method. Including but not 
> limited to {{getClass}}, which allows the user to execute anything using 
> reflection.
> * Implement unit tests for the class and all of its methods.
> * Add comprehensive  and clear documentation to the class and all its public 
> methods so customers can use it without leaving their IDE.



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


[jira] [Closed] (GEODE-7133) Remove overuse of Assert from RegionAdvisor

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7133.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Remove overuse of Assert from RegionAdvisor
> ---
>
> Key: GEODE-7133
> URL: https://issues.apache.org/jira/browse/GEODE-7133
> Project: Geode
>  Issue Type: Improvement
>  Components: functions, regions
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
>  Labels: performance
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Overuse of Assert in RegionAdvisor results in performance impact. Some of the 
> assertions can never be false. Some are in very hot code paths. 
> Profiling locally measured 8% of the CPU time during function execution was 
> spent in Assert.



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


[jira] [Closed] (GEODE-7165) GatewayReceiverImplTest may fail if a port in the test is in use

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7165.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> GatewayReceiverImplTest may fail if a port in the test is in use
> 
>
> Key: GEODE-7165
> URL: https://issues.apache.org/jira/browse/GEODE-7165
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> GatewayReceiverImplTest may fail with a call stack like:
> {noformat}
> org.apache.geode.internal.cache.wan.GatewayReceiverImplTest > 
> startShouldTryAllPortsInPortRangeIfIOExceptionIsThrown FAILED
> org.mockito.exceptions.verification.TooLittleActualInvocations:
> internalCacheServer.start();
> Wanted 101 times:
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImplTest.startShouldTryAllPortsInPortRangeIfIOExceptionIsThrown(GatewayReceiverImplTest.java:167)
> But was 100 times:
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> -> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.tryToStart(GatewayReceiverImpl.java:157)
> {noformat}
> The test is assuming that only the underlying CacheServer will try the ports 
> in the start-end port range. However, I just found this line of code in 
> GatewayReceiverImpl:
> {noformat}
>   private boolean tryToStart(int port) {
> if (!AvailablePort.isPortAvailable(port, SOCKET, getAddress(SOCKET))) {
>   return false;
> }
> {noformat}
> The above early-out will test the availability of the port and exit without 
> interacting with the mock CacheServer provided by the test. Thus, if any of 
> the ports in the range are actually in use on the machine running the test, 
> it will fail.



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


[jira] [Closed] (GEODE-7313) Refactor QuerySecurityBase

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7313.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Refactor QuerySecurityBase
> --
>
> Key: GEODE-7313
> URL: https://issues.apache.org/jira/browse/GEODE-7313
> Project: Geode
>  Issue Type: Improvement
>  Components: querying, tests
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> The {{QuerySecurityBase}} class (base for all OQL and CQ security tests) is 
> currently using deprecated API.
>  Refactor and re-visit these tests (including those in the package 
> {{org.apache.geode.security.query}} that don't extend {{QuerySecurityBase}}), 
> making sure there are not scenarios and/or use cases left aside (also double 
> check that [~jasonhuynh]'s concerns in this 
> [question|https://github.com/apache/geode/pull/4136#discussion_r335049651] 
> are addressed).



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


[jira] [Commented] (GEODE-7626) Break dependency on LocalViewMessage in membership

2019-12-30 Thread ASF subversion and git services (Jira)


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

ASF subversion and git services commented on GEODE-7626:


Commit 10d1b8c4d5de036e773a377b7282c5581514a239 in geode's branch 
refs/heads/develop from Bruce Schuchardt
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=10d1b8c ]

GEODE-7626: Break dependency on LocalViewMessage in membership (#4538)

* GEODE-7626: Break dependency on LocalViewMessage in membership

LocalViewMessage was a DistributionMessage executed in an executor owned
by ClusterDistributionmanager.  This arrangement was very convoluted
because CDM only had upstream involvement in membership view
installation.

This PR moves view installation into GMSMembership using a
single-threaded executor similar to what CDM used but without
statistics.  Stats for the view installation thread have never been
useful so I have not retained that functionality.

There are already many tests for view installation, so while I've
modified a couple I haven't added any new tests.

* make constructor private

* simplifying the executor


> Break dependency on LocalViewMessage in membership
> --
>
> Key: GEODE-7626
> URL: https://issues.apache.org/jira/browse/GEODE-7626
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Dan Smith
>Assignee: Bruce J Schuchardt
>Priority: Major
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7375) Metrics acceptance tests fail due to use of default/hard-coded ports

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7375.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Metrics acceptance tests fail due to use of default/hard-coded ports
> 
>
> Key: GEODE-7375
> URL: https://issues.apache.org/jira/browse/GEODE-7375
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Several metrics acceptance test classes fail consistently on Windows:
>  * RegionEntriesGaugeTest
>  * MemberTypeCommonTagsTest
> These tests either use hard-coded ports or default ports for various 
> purposes. On Windows, the ports sometimes class between tests, causing bind 
> failures.
> Other metrics acceptance test classes are vulnerable to similar failures.
> Example CI failure: 
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsAcceptanceTestOpenJDK11/builds/974]



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


[jira] [Closed] (GEODE-7095) addsMetersForFileDescriptorMetricsBinder test fails: meters is empty

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7095.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> addsMetersForFileDescriptorMetricsBinder test fails: meters is empty
> 
>
> Key: GEODE-7095
> URL: https://issues.apache.org/jira/browse/GEODE-7095
> Project: Geode
>  Issue Type: Bug
>Reporter: Bill Burcham
>Assignee: Aaron Lindsey
>Priority: Major
> Fix For: 1.11.0
>
>
> In this CI build: 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsUnitTestOpenJDK8/builds/766
> The brand new test fails:
> {code}
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest > 
> addsMetersForFileDescriptorMetricsBinder FAILED
> java.lang.AssertionError: 
> Expecting actual not to be empty
> at 
> org.apache.geode.internal.metrics.CacheMeterRegistryFactoryTest.addsMetersForFileDescriptorMetricsBinder(CacheMeterRegistryFactoryTest.java:181)
> {code}
> 10 runs on laptop did not reproduce the issue.



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


[jira] [Closed] (GEODE-7083) Add basic stats to PeerTypeRegistration

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7083.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Add basic stats to PeerTypeRegistration
> ---
>
> Key: GEODE-7083
> URL: https://issues.apache.org/jira/browse/GEODE-7083
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Jacob Barrett
>Assignee: Jacob Barrett
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> PeerTypeRegistration does not have any statistics. Add basic stats for 
> define, create and size of registry. 



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


[jira] [Closed] (GEODE-7281) Ensure that UpdatePassingTokens only moves forward in Git

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7281.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Ensure that UpdatePassingTokens only moves forward in Git
> -
>
> Key: GEODE-7281
> URL: https://issues.apache.org/jira/browse/GEODE-7281
> Project: Geode
>  Issue Type: Task
>  Components: ci
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> During concourse migration, or during a fan-in from parallel tasks, it may 
> happen that Geode SHAs get through the pipeline out-of-order. Ensure that we 
> do not 'move backwards' in git history when this occurs.



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


[jira] [Closed] (GEODE-7175) Convert toData/fromData in other modules to use new serializers

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7175.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Convert toData/fromData in other modules to use new serializers
> ---
>
> Key: GEODE-7175
> URL: https://issues.apache.org/jira/browse/GEODE-7175
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership, serialization
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> The serialization context API provides ObjectSerializer and 
> ObjectDeserializer instances in toData/fromData methods for 
> DataSerializableFixedID classes.  Most implementations of 
> DataSerializableFixedID in geode-core and other subprojects are still using 
> the old DataSerializer.writeObject/readObject API to read and write objects.  
> That should be changed to use the serialization context API.
> DataSerializer.readObject() -> context.getDeserializer().readObject()
> DataSerializer.writeObject() -> context.getSerializer.writeObject()



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


[jira] [Closed] (GEODE-7131) add bi-direction linkage to Region and index in REST API V2

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7131.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> add bi-direction linkage to Region and index in REST API V2
> ---
>
> Key: GEODE-7131
> URL: https://issues.apache.org/jira/browse/GEODE-7131
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Gang Yan
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 7h
>  Remaining Estimate: 0h
>
> for region and index, they are related.
> currently, in the output of json, the customers can not find the relation 
> between region and index.
>  
> ### WHAT
>  # add the link of index to region , if the region has index
>  # add the link of region to index
> for region:
>    in "config" part, add a link of "indexes:  
> /management/experimental/regionname/indexes"
> for index:
>    in "config" part, add a link of "region:  
> /management/experimental/regionname"



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


[jira] [Closed] (GEODE-7386) CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with AssertionError

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7386.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI failure: JmxCredentialTypeTest > testWithNonStringCredential failed with 
> AssertionError
> --
>
> Key: GEODE-7386
> URL: https://issues.apache.org/jira/browse/GEODE-7386
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, management, security
>Reporter: Barrett Oglesby
>Assignee: Jinmei Liao
>Priority: Major
> Fix For: 1.11.0
>
>
> This test has failed in the last 2 IntegrationTestOpenJDK8 builds:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1223
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/1224
> {noformat}
> org.apache.geode.management.internal.security.JmxCredentialTypeTest > 
> testWithNonStringCredential FAILED
> java.lang.AssertionError: 
> Expecting:
>  <"Unsupported type: java.lang.Integer">
> to contain:
>  <"filter status: REJECTED"> 
> at 
> org.apache.geode.management.internal.security.JmxCredentialTypeTest.testWithNonStringCredential(JmxCredentialTypeTest.java:47)
> {noformat}



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


[jira] [Closed] (GEODE-7270) WanAutoDiscoveryDUnitTest. test_TK_Recognises_LN_AND_NY

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7270.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> WanAutoDiscoveryDUnitTest. test_TK_Recognises_LN_AND_NY
> ---
>
> Key: GEODE-7270
> URL: https://issues.apache.org/jira/browse/GEODE-7270
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Mark Hanson
>Assignee: Xiaojian Zhou
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> WanAutoDiscoveryDUnitTest. test_TK_Recognises_LN_AND_NY failed with a Null 
> Pointer Exception.
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/1138]
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0174/test-results/distributedTest/1570043011/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0174/test-artifacts/1570043011/distributedtestfiles-OpenJDK8-1.11.0-SNAPSHOT.0174.tgz]
>  
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest$$Lambda$172/1647741944.run
>  in VM 0 running on Host 1cafba0ee536 with 8 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.internal.cache.wan.misc.WanAutoDiscoveryDUnitTest.test_TK_Recognises_LN_AND_NY(WanAutoDiscoveryDUnitTest.java:228)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
>   at 
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispat

[jira] [Closed] (GEODE-7355) Break dependencies on DistributionStats

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7355.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Break dependencies on DistributionStats
> ---
>
> Key: GEODE-7355
> URL: https://issues.apache.org/jira/browse/GEODE-7355
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Ernest Burghardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7219) BufferUnderflowException in PutReplyMessage deserialization

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7219.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> BufferUnderflowException in PutReplyMessage deserialization
> ---
>
> Key: GEODE-7219
> URL: https://issues.apache.org/jira/browse/GEODE-7219
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> I ran into this exception in three different regression tests and see history 
> of it happening in other people's tests.  I think it's due to 
> VersionTag.toData() making serialization decisions at the same time some 
> other thread is modifying the version tag.
> {noformat}
> [fatal 2019/09/18 00:47:52.835 PDT  rs-Awesome-549-1146a0i3large-hydra-client-10(bridgegemfire1_host1_12399:12399):41001
>  unshared ordered uid=452 dom #2 port=46062> tid=0xdd] Error deserializing 
> message
> java.nio.BufferUnderflowException
>   at java.nio.Buffer.nextGetIndex(Buffer.java:500)
>   at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:249)
>   at 
> org.apache.geode.internal.tcp.ByteBufferInputStream$ByteBufferByteSource.get(ByteBufferInputStream.java:206)
>   at 
> org.apache.geode.internal.tcp.ByteBufferInputStream.readByte(ByteBufferInputStream.java:892)
>   at 
> org.apache.geode.internal.serialization.StaticSerialization.readArrayLength(StaticSerialization.java:102)
>   at 
> org.apache.geode.internal.serialization.StaticSerialization.readByteArray(StaticSerialization.java:321)
>   at 
> org.apache.geode.internal.serialization.StaticSerialization.readInetAddress(StaticSerialization.java:254)
>   at 
> org.apache.geode.DataSerializer.readInetAddress(DataSerializer.java:463)
>   at 
> org.apache.geode.distributed.internal.membership.InternalDistributedMember._readEssentialData(InternalDistributedMember.java:1085)
>   at 
> org.apache.geode.distributed.internal.membership.InternalDistributedMember.readEssentialData(InternalDistributedMember.java:1079)
>   at 
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:58)
>   at 
> org.apache.geode.internal.cache.versions.VMVersionTag.readMember(VMVersionTag.java:31)
>   at 
> org.apache.geode.internal.cache.versions.VersionTag.fromData(VersionTag.java:412)
>   at 
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
>   at 
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
>   at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
>   at 
> org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2639)
>   at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2864)
>   at 
> org.apache.geode.internal.cache.partitioned.PutMessage$PutReplyMessage.fromData(PutMessage.java:940)
>   at 
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.invokeFromData(DSFIDSerializerImpl.java:300)
>   at 
> org.apache.geode.internal.serialization.DSFIDSerializerImpl.create(DSFIDSerializerImpl.java:347)
>   at org.apache.geode.internal.DSFIDFactory.create(DSFIDFactory.java:1018)
>   at 
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2520)
>   at 
> org.apache.geode.internal.InternalDataSerializer.readDSFID(InternalDataSerializer.java:2534)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessage(Connection.java:3118)
>   at 
> org.apache.geode.internal.tcp.Connection.processInputBuffer(Connection.java:2927)
>   at 
> org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1752)
>   at org.apache.geode.internal.tcp.Connection.run(Connection.java:1584)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>   at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This code is trying to read a "previous member ID" for the version tag but 
> there isn't one.  The decision to write one or not comes from this code:
> {code}
> if (this.previousMemberID != null
> && (this.previousMemberID != this.memberID || !includeMember)) {
>   writeMember(this.previousMemberID, out);
> }
> {code}
> but flags have already been written telling deserialization code whether or 
> not to read this field:
> {code}
> if (this.previousMemberID != null) {
>   flags |= HAS_PREVIOUS_MEMBER_ID;
>   if

[jira] [Closed] (GEODE-7308) Upgrade Jetty from 9.4.12.v20180830 to 9.4.21.v20190926

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7308.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Upgrade Jetty from 9.4.12.v20180830 to 9.4.21.v20190926 
> 
>
> Key: GEODE-7308
> URL: https://issues.apache.org/jira/browse/GEODE-7308
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7278) v2 rest api GatewayReceiver drops GatewayTransportFilters

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7278.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> v2 rest api GatewayReceiver drops GatewayTransportFilters
> -
>
> Key: GEODE-7278
> URL: https://issues.apache.org/jira/browse/GEODE-7278
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.10.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Code inspection of the 
> org.apache.geode.management.internal.configuration.converters.GatewayReceiverConverter
>  shows that it does not convert the GatewayTransportFilters.
> This should have caused some tests to fail so coverage needs to be added.



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


[jira] [Closed] (GEODE-7362) Break dependencies on version class

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7362.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Break dependencies on version class
> ---
>
> Key: GEODE-7362
> URL: https://issues.apache.org/jira/browse/GEODE-7362
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Ernest Burghardt
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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


[jira] [Closed] (GEODE-7372) gfsh shutdown --include-locators confirmation is ignored

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7372.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> gfsh shutdown --include-locators confirmation is ignored
> 
>
> Key: GEODE-7372
> URL: https://issues.apache.org/jira/browse/GEODE-7372
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The gfsh shutdown command prompts the User for confirmation of the shutdown. 
> If the User types {{n}} for no, it should abort and do nothing. However, the 
> shutdown proceeds and shuts down the entire cluster including the locator 
> regardless of how the User answers the prompt.
> {noformat}
> gfsh>shutdown --include-locators
> As a lot of data in memory will be lost, including possibly events in queues, 
> do you really want to shutdown the entire distributed system? (Y/n): n
> Shutdown is triggered
> {noformat}



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


[jira] [Closed] (GEODE-6992) Deprecate allowUntrustedMethodInvocation System Property

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6992.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Deprecate allowUntrustedMethodInvocation System Property
> 
>
> Key: GEODE-6992
> URL: https://issues.apache.org/jira/browse/GEODE-6992
> Project: Geode
>  Issue Type: New Feature
>  Components: configuration
>Reporter: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Deprecate the system property 
> {{gemfire.QueryService.allowUntrustedMethodInvocation}}.
> Register a {{warning}} message on the logs whenever the member detects that 
> the property is being used so our users are aware of the deprecation.



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


[jira] [Closed] (GEODE-7112) CI failure: TxnTimeOutDUnitTest.testLoginTimeOut is flaky

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7112.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI failure: TxnTimeOutDUnitTest.testLoginTimeOut is flaky
> -
>
> Key: GEODE-7112
> URL: https://issues.apache.org/jira/browse/GEODE-7112
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Affects Versions: 1.11.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This test is flaky, as test may be timed out later than expected due to 
> resources constraints during the test run.
> [vm0] [info 2019/08/21 00:11:05.805 GMT  
> tid=0x4f] Received method: 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest$$Lambda$329/0x000840585840.run
>  with 0 args on object: 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest$$Lambda$329/0x000840585840@53dab2f9
> [vm0] [warn 2019/08/21 00:11:11.536 GMT  tid=0x3d] Statistics 
> sampling thread detected a wakeup delay of 3487 ms, indicating a possible 
> resource issue. Check the GC, memory, and CPU statistics.
> [vm0] [info 2019/08/21 00:11:11.677 GMT  tid=0x3e] 
> Transaction org.apache.geode.internal.jta.GlobalTransaction@5c6195b9 has 
> timed out.
> [locator] [warn 2019/08/21 00:11:11.851 GMT  tid=0x3c] 
> Statistics sampling thread detected a wakeup delay of 3293 ms, indicating a 
> possible resource issue. Check the GC, memory, and CPU statistics.
> [vm0] [info 2019/08/21 00:11:12.134 GMT  
> tid=0x22] Got result: null
> [vm0]  from 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest$$Lambda$328/0x000840586440.run
>  with 0 args on object: 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest$$Lambda$328/0x000840586440@36607038
>  (took 6330 ms)
> [info 2019/08/21 00:11:12.354 GMT  tid=0x1b] Thread Thread[run 
> invoked on an instance of 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest$$Lambda$157/0x00084023ac40,5,]
>  took 6404 ms to exit.
> [vm0] [info 2019/08/21 00:11:12.464 GMT  
> tid=0x4f] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: Exception did not occur although was supposed 
> to occur
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest.runTest1(TxnTimeOutDUnitTest.java:216)
> [vm0] at 
> org.apache.geode.internal.jta.dunit.TxnTimeOutDUnitTest.lambda$testLoginTimeOut$61fe3738$1(TxnTimeOutDUnitTest.java:186)
> [vm0] at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [vm0] at 
> org.apache.geode.test.dunit.internal.MethodInvoker.executeObject(MethodInvoker.java:123)
> [vm0] at 
> org.apache.geode.test.dunit.internal.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:69)
> [vm0] at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> [vm0] at 
> java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
> [vm0] at 
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at 
> java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.base/java.security.AccessController.doPrivileged(Native 
> Method)
> [vm0] at 
> java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
> [vm0] at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796)
> [vm0] at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:677)
> [vm0] at java.base/java.security.AccessController.doPrivileged(Native 
> Method)
> [vm0] at 
> java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:676)
> [vm0] at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.jav

[jira] [Closed] (GEODE-7334) dev rest api failed to start when a JodaModel jar exists in the classpath

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7334.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> dev rest api failed to start when a JodaModel jar exists in the classpath
> -
>
> Key: GEODE-7334
> URL: https://issues.apache.org/jira/browse/GEODE-7334
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Jinmei Liao
>Priority: Major
> Fix For: 1.11.0
>
> Attachments: jackson-datatype-joda-2.9.8.jar, joda-time-2.1.jar
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Steps to reproduce
> 1. Add jackson-datatype-joda-2.9.8.jarand joda-time-2.1.jar in the 
> server classpath
> 2. start the server with rest api started
> 3. examine the server log shows the following exception:
> [error 2019/09/13 05:43:21.681 BST rd1-server  tid=0x1] Context 
> initialization failed
> org.springframework.beans.factory.BeanCreationException: Error creating bean 
> with name 
> 'org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter':
>  Instantiation of bean failed; nested exception is 
> org.springframework.beans.BeanInstantiationException: Failed to instantiate 
> [org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter]:
>  Constructor threw exception; nested exception is 
> java.lang.ClassCastException: com.fasterxml.jackson.datatype.joda.JodaModule 
> cannot be cast to com.fasterxml.jackson.databind.Module
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1163)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:1107)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:513)
> at 
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:483)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312)
> at 
> org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:230)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308)
> at 
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197)
> at 
> org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:761)
> at 
> org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:867)
> at 
> org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:543)
> at 
> org.springframework.web.servlet.FrameworkServlet.configureAndRefreshWebApplicationContext(FrameworkServlet.java:668)
> at 
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:634)
> at 
> org.springframework.web.servlet.FrameworkServlet.createWebApplicationContext(FrameworkServlet.java:682)
> at 
> org.springframework.web.servlet.FrameworkServlet.initWebApplicationContext(FrameworkServlet.java:553)
> at 
> org.springframework.web.servlet.FrameworkServlet.initServletBean(FrameworkServlet.java:494)
> at 
> org.springframework.web.servlet.HttpServletBean.init(HttpServletBean.java:171)
> at javax.servlet.GenericServlet.init(GenericServlet.java:244)
> at 
> org.eclipse.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:670)
> at 
> org.eclipse.jetty.servlet.ServletHolder.initialize(ServletHolder.java:427)
> at 
> org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:760)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:374)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1497)
> at 
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1459)
> at 
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:847)
> at 
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:287)
> at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:545)
> at 
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
> at 
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:138)
> at 
> org.ecl

[jira] [Closed] (GEODE-7379) Break dependencies on CancelException class

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7379.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Break dependencies on CancelException class
> ---
>
> Key: GEODE-7379
> URL: https://issues.apache.org/jira/browse/GEODE-7379
> Project: Geode
>  Issue Type: Sub-task
>  Components: membership
>Reporter: Bill Burcham
>Assignee: Ernest Burghardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> eliminate this rule in {{TcpServerDependenciesTest}}
> {code}
>   // TODO - cancel excpetion
>   .or(type(CancelException.class))
> {code}



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


[jira] [Closed] (GEODE-7140) Rename the meters for entries

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7140.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Rename the meters for entries
> -
>
> Key: GEODE-7140
> URL: https://issues.apache.org/jira/browse/GEODE-7140
> Project: Geode
>  Issue Type: Improvement
>  Components: statistics
>Reporter: Mark Hanson
>Assignee: Mark Hanson
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Rename metric 'member.region.entries' to 'geode.cache.entries'
> Rename tag 'region_name' to 'region'



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


[jira] [Closed] (GEODE-7185) Use proper Gradle configuration for new serialization module

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7185.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Use proper Gradle configuration for new serialization module
> 
>
> Key: GEODE-7185
> URL: https://issues.apache.org/jira/browse/GEODE-7185
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Robert Houghton
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The geode-serialization module split from geode-core contains classes only 
> within the internal package. So the configuration of the dependency should be 
> implementation, not api.



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


[jira] [Closed] (GEODE-7178) Older versions of Native Client broken in 1.9+ due to missing compatibility code

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7178.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Older versions of Native Client broken in 1.9+ due to missing compatibility 
> code
> 
>
> Key: GEODE-7178
> URL: https://issues.apache.org/jira/browse/GEODE-7178
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Blake Bender
>Assignee: Michael Oleske
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> When getting a request to perform an operation, the code does not check for 
> instance of Byte.  Native client sends the operation as a Byte, which 
> currently cause Geode to throws a
> {{java.lang.ClassCastException: class java.lang.Byte cannot be cast to class 
> org.apache.geode.cache.Operation}}
>  
> Server versions prior to 1.9.0 had a compatibility check for this Byte



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


[jira] [Closed] (GEODE-130) Suppress proprietary API compiler warnings

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-130.
-

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Suppress proprietary API compiler warnings
> --
>
> Key: GEODE-130
> URL: https://issues.apache.org/jira/browse/GEODE-130
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Anthony Baker
>Assignee: Jacob Barrett
>Priority: Trivial
> Fix For: 1.11.0
>
>  Time Spent: 3h 50m
>  Remaining Estimate: 0h
>
> Geode uses several internal JDK classes like SignalHandler and Unsafe.  These 
> generate compiler warnings like:
> {noformat}
> /Users/abaker/code/incubator-geode/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/shell/unsafe/GfshSignalHandler.java:73:
>  warning: SignalHandler is internal proprietary API and may be removed in a 
> future release
> return (handler == SignalHandler.SIG_DFL || handler == 
> SignalHandler.SIG_IGN ? null : handler);
> {noformat}
> It would be nice to suppress these using the {{-XDignore.symbol.file=true}} 
> javac argument 
> ([1|http://stackoverflow.com/questions/4065401/using-internal-sun-classes-with-javac])
>  to remove noise from the build output.  Looks like the only way to do this 
> is to fork the javac compiler from gradle 
> ([2|https://discuss.gradle.org/t/passing-arguments-to-compiler-and-javadoc/1661])
>  and add a compiler arg:
> {noformat}
> options.fork = true
> options.forkOptions.executable = 'javac'
> options.compilerArgs << '-XDignore.symbol.file'
> {noformat}
> I'm not sure it's worth the performance hit of forking javac to suppress the 
> warnings.
> Of course, we will need to address usage of these API's in Java9 as we will 
> not have access to internal JDK classes (due to Project Jigsaw).



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


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

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7279.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> 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] [Closed] (GEODE-7250) LuceneSearchWithRollingUpgradeDUnit not sorting correctly.

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7250.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> LuceneSearchWithRollingUpgradeDUnit not sorting correctly.
> --
>
> Key: GEODE-7250
> URL: https://issues.apache.org/jira/browse/GEODE-7250
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Mark Hanson
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> UpgradetestOpenJDK8 is failing... 
> Someone should look at version manager and make sure it is handling version 
> correctly in light of 1.10.0
> from error logs:
> *running against these versions: [1.10.0, 1.2.0, 1.3.0, 1.4.0, 1.5.0, 1.6.0, 
> 1.7.0, 1.8.0, 1.9.0, 1.9.1]* 
> *Bouncing VM0 from version 0.0.0 to 1.10.0*
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/1110]
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>  
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0165/test-results/upgradeTest/1569530010/]
>  
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.11.0-SNAPSHOT.0165/test-artifacts/1569530010/upgradetestfiles-OpenJDK8-1.11.0-SNAPSHOT.0165.tgz]



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


[jira] [Closed] (GEODE-7339) move "experimental" out of url

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7339.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> move "experimental" out of url
> --
>
> Key: GEODE-7339
> URL: https://issues.apache.org/jira/browse/GEODE-7339
> Project: Geode
>  Issue Type: Improvement
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Priority: Major
> Fix For: 1.11.0
>
>
> # WHY
> * reduce the migration cost of customers for future formal release
> * encourage developer to use it
>  
> # WHAT
> * replace "experimental" with "v1" in the url
> * update the documentation about url updates
> * update the documentation to tag all the endpoint as experimental



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


[jira] [Closed] (GEODE-7473) when the sender is not ready, before adding to tmpDroppedEvents, should check its destination dsid

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7473.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> when the sender is not ready, before adding to tmpDroppedEvents, should check 
> its destination dsid
> --
>
> Key: GEODE-7473
> URL: https://issues.apache.org/jira/browse/GEODE-7473
> Project: Geode
>  Issue Type: Bug
>Reporter: Xiaojian Zhou
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> When WAN receiver received an event, if its region also defined a sender, it 
> will check event's GatewaySenderEventCallbackArgument's dsIds to see if it 
> should be  filtered out. 
> WAN used this logic to prevent the event from bouncing back to wrong site, 
> such as original sender. 
> In GEODE-5087's fix, when found sender is not available and add to 
> tmpDroppedEvents before checking event's GatewaySenderEventCallbackArgument. 
> This should be done after checking GatewaySenderEventCallbackArgument.



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


[jira] [Closed] (GEODE-7259) Function Execution Through REST API Limitation

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7259.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Function Execution Through REST API Limitation
> --
>
> Key: GEODE-7259
> URL: https://issues.apache.org/jira/browse/GEODE-7259
> Project: Geode
>  Issue Type: Bug
>  Components: docs, rest (dev)
>Reporter: Juan Ramos
>Assignee: Alberto Bustamante Reyes
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Function execution through the {{REST API}} doesn't support nested 
> collections as part of the parameters, this is an undocumented limitation.
> We basically try to convert the {{JSON}} parameters into a {{Map}} and 
> afterwards, based on the {{Map}} contents and the {{@type}} value within the 
> JSON string, convert that into the actual {{Object[]}} parameters expected by 
> the function. If any of those objects contain an inner collection ([] as 
> JSON) or object ({} as JSON), the initial parsing will always fail:
> {code:title=AbstractBaseController.java|borderStyle=solid}
> private Map convertJsonToMap(final String jsonString) {
> Map map = new HashMap();
> // convert JSON string to Map
> try {
>   map = objectMapper.readValue(jsonString, new 
> TypeReference>() {});
> } catch (JsonParseException e) {
>   throw new MalformedJsonException(
>   "Bind params specified as JSON document in the request is 
> incorrect!", e);
> } catch (JsonMappingException e) {
>   throw new MalformedJsonException(
>   "Server unable to process bind params specified as JSON document in 
> the request!", e);
> } catch (IOException e) {
>   throw new GemfireRestException("Server has encountered error while 
> process this request!", e);
> }
> return map;
>   }
> {code}



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


[jira] [Closed] (GEODE-7291) Cluster and Member micrometer common tags should not be used with empty values

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7291.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Cluster and Member micrometer common tags should not be used with empty values
> --
>
> Key: GEODE-7291
> URL: https://issues.apache.org/jira/browse/GEODE-7291
> Project: Geode
>  Issue Type: Improvement
>  Components: statistics
>Affects Versions: 1.11.0
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Creating tags without values is something that Micrometer recommends against 
> doing. With our common tags we need to consider the implications of adding 
> them outside of a server/locator member of a cluster.
> {code}
> Given I create a cache without a member name 
> When I add a meterregistry to that cache
> Then I should not see the member common tag:
> - member
> And I should see the following common tags:
> - cluster
> - host
> - member_type
> {code}
> {code}
> Given I create a clientcache through Java
> When I add a meterregistry to that cache
> Then I should not see the following common tags:
> - cluster
> And I should see the following common tags:
> - host
> - member
> - member_type
> {code}



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


[jira] [Closed] (GEODE-7289) StandaloneClientManagementAPIAcceptanceTest uses default JMX port

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7289.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> StandaloneClientManagementAPIAcceptanceTest uses default JMX port
> -
>
> Key: GEODE-7289
> URL: https://issues.apache.org/jira/browse/GEODE-7289
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> StandaloneClientManagementAPIAcceptanceTest picks random ports for locator 
> port and http service port, but uses default for jmx manager port.



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


[jira] [Closed] (GEODE-7152) AlertAppender recursion causes ForcedDisconnect to hang

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7152.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> AlertAppender recursion causes ForcedDisconnect to hang
> ---
>
> Key: GEODE-7152
> URL: https://issues.apache.org/jira/browse/GEODE-7152
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>
> AlertAppender uses a ThreadLocal to prevent recursive calls from actually 
> doing anything. However, a recent upgrade to our log4j dependencies seems to 
> have changed the behavior such that log4j refuses to invoke {{doAppend}} if 
> the thread is currently handling a {{sendAlert}} initiated from {{doAppend}}. 
> To fix this bug, we will need to change {{sendAlert}} to be asynchronous.
> In this run we are expecting ForcedDisconnects, but they don't occur until 
> after the hang is declared.
> The appearance of these "Recursive call to appender" messages is new:
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to 
> appender ALERT
> {noformat}
> \*** Test is dropping the network
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log: 
> [info 2019/08/12 21:37:46.265 PDT  
> tid=0x94] Dropping network connection from 
> rs-FullRegression13040513a0i3large-hydra-client-46 to 
> rs-FullRegression13040513a0i3large-hydra-client-1 and from 
> rs-FullRegression13040513a0i3large-hydra-client-1 to 
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** Here are the appender messages
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,554 Geode Failure Detection thread 6 ERROR Recursive call to 
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,554 Geode Failure Detection thread 4 ERROR Recursive call to 
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,554 Geode Failure Detection thread 5 ERROR Recursive call to 
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,556 Geode Failure Detection thread 5 ERROR Recursive call to 
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,558 Geode Failure Detection thread 4 ERROR Recursive call to 
> appender ALERT
> wan_bridgeNetworkPartition1-0812-213411/bgexec15919_14066.log: 2019-08-12 
> 21:37:47,559 Geode Failure Detection thread 4 ERROR Recursive call to 
> appender ALERT
> {noformat}
> \*** network is dropped
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/vm_9_locator_1_2_host2_13435.log: 
> [info 2019/08/12 21:37:47.136 PDT  
> tid=0x94] Dropped network connection from 
> rs-FullRegression13040513a0i3large-hydra-client-46 to 
> rs-FullRegression13040513a0i3large-hydra-client-1 and from 
> rs-FullRegression13040513a0i3large-hydra-client-1 to 
> rs-FullRegression13040513a0i3large-hydra-client-46
> {noformat}
> \*** hang is declared
> {noformat}
> wan_bridgeNetworkPartition1-0812-213411/taskmaster_15326.log: [severe 
> 2019/08/12 21:40:44.626 PDT  tid=0x1] Result for 
> vm_12_thr_16_wan1Lose_host1_14084: TASK[0] 
> splitBrain.NetworkPartitionTest.HydraTask_doEntryOperations: HANG a client 
> exceeded max result wait sec: 180
> {noformat}
> \*** now we see ForcedDisconnects
> {noformat}
> [fatal 2019/08/12 21:40:57.826 PDT  receiver,rs-FullRegression13040513a0i3large-hydra-client-46-43284> tid=0x24] 
> Membership service failure: Membership coordinator 
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared 
> that a network partition has occurred
> org.apache.geode.ForcedDisconnectException: Membership coordinator 
> 10.32.110.145(gemfire3_host1_14066:14066:locator):41000 has declared 
> that a network partition has occurred
> at 
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2506)
> at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1106)
> at 
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1481)
> at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1328)
> at 
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1266)
> at org.

[jira] [Closed] (GEODE-7120) Adjust pipeline values to avoid timeouts and out of memory failures

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7120.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Adjust pipeline values to avoid timeouts and out of memory failures
> ---
>
> Key: GEODE-7120
> URL: https://issues.apache.org/jira/browse/GEODE-7120
> Project: Geode
>  Issue Type: Wish
>  Components: ci
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Adjust pipeline values to avoid timeouts and out of memory failures:
> * Increase distributedTest RAM memory from 180 to 250
> * Increase rsync timeout from 5m to 10m
> * Increase acceptanceTest timeout from 45m to 1h
> The distributedTest RAM needs to be increased to avoid Jetty/Tomcat out of 
> memory failures when forking new processes:
> {noformat}
> org.apache.geode.session.tests.Jetty9CachingClientServerTest > 
> containersShouldHavePersistentSessionData FAILED
> java.lang.RuntimeException: Something very bad happened when trying to 
> start container 
> JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05_
> Caused by:
> java.lang.RuntimeException: Something very bad happened to this 
> container when starting. Check the cargo_logs folder for container logs.
> Caused by:
> java.io.IOException: Unable to run modify_war script, command: 
> [/tmp/geode_container_install17845041006471328987/cargo_modules/Apache_Geode_Modules-1.11.0-SNAPSHOT-AppServer/bin/modify_war,
>  -J, -Xmx2096m, -w, 
> /home/geode/geode/geode-assembly/build/distributedTest254/../../../extensions/session-testing-war/build/libs/session-testing-war.war,
>  -t, client-server, -o, 
> /tmp/geode_container_install17845041006471328987/cargo_wars/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f053692095078744488223.war,
>  -p, gemfire.cache.enable_local_cache=true, -p, 
> gemfire.property.log-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/gemfire.log,
>  -p, 
> gemfire.property.cache-xml-file=/home/geode/geode/geode-assembly/build/distributedTest254/cargo_logs/JETTY9_client-server_containersShouldHavePersistentSessionData_0_a6ebd229-072b-47db-a9bf-ca3713175f05/cache-client.xml]
> log file: 
> ERROR: Error updating web.xml
> ng: INFO: os::commit_memory(0x00077d00, 2147483648, 0) 
> failed; error='Not enough space' (errno=12)
> {noformat}
> The actual failure from OpenJDK is:
> {noformat}
> OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x7f74a4ba4000, 
> 65536, 1) failed; error='Not enough space' (errno=12) 
> [thread 26510 also had an error]
> {noformat}
> The rsync timeout needs to be increased to avoid these timeouts:
> {noformat}
> BUILD SUCCESSFUL in 12s
> 1 actionable task: 1 up-to-date
> + rsync -e 'ssh -i instance-data/sshkey -o ConnectionAttempts=60 -o 
> StrictHostKeyChecking=no' -ah geode@10.0.0.116:geode 
> /tmp/build/1a3d1be6/geode-results/
> rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(642) 
> [generator=3.1.3]
> rsync error: received SIGUSR1 (code 19) at main.c(1440) [receiver=3.1.3]
> rsync: [generator] write error: Broken pipe (32)
> timeout exceeded
> {noformat}
> The acceptanceTest timeout needs to be increased from 45m to 1h:
> {noformat}
> > Task :geode-connectors:acceptanceTest
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.geode.internal.size.ObjectTraverser 
> (file:/home/geode/geode/geode-core/build/libs/geode-core-1.11.0-SNAPSHOT.jar) 
> to field java.lang.String.value
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.geode.internal.size.ObjectTraverser
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by 
> org.apache.geode.internal.size.ObjectTraverser 
> (file:/home/geode/geode/geode-core/build/libs/geode-core-1.11.0-SNAPSHOT.jar) 
> to field java.lang.String.value
> WARNING: Please consider reporting this to the maintainers of 
> org.apache.geode.internal.size.ObjectTraverser
> WARNING: Use --illegal-access=warn to enable warnings of further illegal 
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> timeout exceede

[jira] [Closed] (GEODE-7241) Artifacts for geode-web and geode-web-api are jars instead of wars in maven central

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7241.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Artifacts for geode-web and geode-web-api are jars instead of wars in maven 
> central
> ---
>
> Key: GEODE-7241
> URL: https://issues.apache.org/jira/browse/GEODE-7241
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Affects Versions: 1.8.0, 1.9.0, 1.9.1, 1.10.0
>Reporter: Udo Kohlmeyer
>Assignee: Robert Houghton
>Priority: Major
> Fix For: 1.9.2, 1.11.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> In maven central the artifact for `geode-web` and `geode-web-api` are jars 
> instead of the expected wars.
> This seems to be problem with the build/publish script that seems to have 
> changed in 1.8.
> As this problem started in 1.8
> This has become a problem when running the Spring Data Geode examples and 
> tests. The functionality that is now impeded, is the ability to start a 
> Server with HTTP enabled using only maven/gradle dependency management. The 
> functionality to enable this was enabled by GEODE-5660, the ability to find 
> the `geode-web` and `geode-web-api` artifacts on the classpath.
> Removing this ability will hinder users to effectively run any GEODE 
> integration tests which might want to use the REST interfaces. Making sure 
> that the correct version of the Geode project is installed in order to start 
> a server(s) is a little cumbersome.



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


[jira] [Closed] (GEODE-7384) OldId from the same distributed member should be removed when processing the dm's PrepareNewPersistentMemberMessage

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7384.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> OldId from the same distributed member should be removed when processing the 
> dm's PrepareNewPersistentMemberMessage
> ---
>
> Key: GEODE-7384
> URL: https://issues.apache.org/jira/browse/GEODE-7384
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.1.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> The old id is being removed only if the PersistenceAdvisorImpl is initialized 
> when processing the message. However, this could lead to two 
> PersistentMemberIDs from the same member being persisted and there is no way 
> that the old id can be removed.



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


[jira] [Closed] (GEODE-6988) Implement JavaBeanAccessorMethodAuthorizer

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6988.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Implement JavaBeanAccessorMethodAuthorizer
> --
>
> Key: GEODE-6988
> URL: https://issues.apache.org/jira/browse/GEODE-6988
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Juan Ramos
>Assignee: Donal Evans
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Implement the [JavaBeanAccessorMethodAuthorizer 
> |https://cwiki.apache.org/confluence/display/GEODE/OQL+Method+Invocation+Security#OQLMethodInvocationSecurity-JavaBeanAccessorMethodAuthorizer]
>  class.
> * Make sure the class is immutable and thread safe.
> * Implement unit tests for the class and all of its methods.
> * Add comprehensive  and clear documentation to the class and all its public 
> methods so customers can use it without leaving their IDE.



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


[jira] [Closed] (GEODE-6907) More Quick Examples

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-6907.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> More Quick Examples
> ---
>
> Key: GEODE-6907
> URL: https://issues.apache.org/jira/browse/GEODE-6907
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Juan Ramos
>Assignee: Juan Ramos
>Priority: Major
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Add some examples showing how the aggregate functions can be used to 
> [Querying FAQ and 
> Examples|https://geode.apache.org/docs/guide/19/getting_started/querying_quick_reference.html].



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


[jira] [Closed] (GEODE-7168) CI failure: Tomcat8ClientServerRollingUpgradeTest > canDoARollingUpgradeOfGeodeServersWithSessionModules[191]

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7168.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> CI failure: Tomcat8ClientServerRollingUpgradeTest > 
> canDoARollingUpgradeOfGeodeServersWithSessionModules[191]
> -
>
> Key: GEODE-7168
> URL: https://issues.apache.org/jira/browse/GEODE-7168
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Bruce J Schuchardt
>Assignee: Bruce J Schuchardt
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Recent changes to this test require that there be a Version for any 
> geode-old-version we're going to test against.  We don't typically create 
> Versions for patch releases like 1.9.1 and this is making the test throw NPEs.
> {noformat}
> > Task :geode-assembly:upgradeTest
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest > 
> canDoARollingUpgradeOfGeodeServersWithSessionModules[191] FAILED
> java.lang.NullPointerException
> at 
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.getClassPathTomcat8AndOldModules(Tomcat8ClientServerRollingUpgradeTest.java:312)
> at 
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.setup(Tomcat8ClientServerRollingUpgradeTest.java:154)
> java.lang.NullPointerException
> at 
> org.apache.geode.session.tests.Tomcat8ClientServerRollingUpgradeTest.stop(Tomcat8ClientServerRollingUpgradeTest.java:181)
> {noformat}



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


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

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7360.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> 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
>  Labels: GeodeCommons
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> 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] [Closed] (GEODE-5584) Switch concourse template generation from spruce to jinja

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-5584.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> Switch concourse template generation from spruce to jinja
> -
>
> Key: GEODE-5584
> URL: https://issues.apache.org/jira/browse/GEODE-5584
> Project: Geode
>  Issue Type: Task
>Reporter: Finn Southerland
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.11.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The meta scripts currently use spruce to assemble the other pipeline 
> templates. They should use jinja, because it is more readable and will be 
> easier to extend.



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


[jira] [Closed] (GEODE-7092) ReconnectWithUDPSecurityDUnitTest fails due to insufficient MEMBER_TIMEOUT

2019-12-30 Thread Mark Hanson (Jira)


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

Mark Hanson closed GEODE-7092.
--

Transition from Resolved to Closed for Apache Geode 1.11.0 RC4 release.

> ReconnectWithUDPSecurityDUnitTest fails due to insufficient MEMBER_TIMEOUT
> --
>
> Key: GEODE-7092
> URL: https://issues.apache.org/jira/browse/GEODE-7092
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
> Fix For: 1.11.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Flaky test. In this CI run:
>  
> [https://concourse.gemfire-ci.info/teams/main/pipelines/gemfire-develop-main/jobs/DistributedTestOpenJDK8/builds/879]
>  
> These two tests failed:
>  
> ReconnectWithUDPSecurityDUnitTest > testReconnectOnForcedDisconnect
> ReconnectWithUDPSecurityDUnitTest > testReconnectCollidesWithApplication
>  
> They both boil down to:
>  
> doTestReconnectOnForcedDisconnect() which calls 
> getDistributedSystemProperties() to get property values to set. 
> MEMBER_TIMEOUT is set to 1 second which is insufficient.



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


  1   2   3   >