[GitHub] geode-native pull request #90: GEODE-2763: Remove of nonSingleHopsCount stat...

2017-04-13 Thread ameybarve15
GitHub user ameybarve15 opened a pull request:

https://github.com/apache/geode-native/pull/90

GEODE-2763: Remove of nonSingleHopsCount stat in client

GEODE-2763: Remove of nonSingleHopsCount stat in client from 
1. source 
2. cpp and csharp unit tests and
3. documentation.

Ran unit tests and integration-tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ameybarve15/geode-native feature/GEODE-2763

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-native/pull/90.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #90


commit 41882663a30f44f1ce9d12235802768e932945b2
Author: Amey Barve 
Date:   2017-04-11T09:50:02Z

GEODE-2763: Remove of nonSingleHopsCount stat in client from  1. source
2. cpp and csharp unit tests 3. documentation.

commit 15705e9cab99b030d9e45ae618b6aad9084c5cd9
Author: Amey Barve 
Date:   2017-04-13T05:50:00Z

Merge branch 'develop' of https://github.com/apache/geode-native into 
feature/GEODE-2763




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2763) Remove of nonSingleHopsCount stat in client

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2763:
---

GitHub user ameybarve15 opened a pull request:

https://github.com/apache/geode-native/pull/90

GEODE-2763: Remove of nonSingleHopsCount stat in client

GEODE-2763: Remove of nonSingleHopsCount stat in client from 
1. source 
2. cpp and csharp unit tests and
3. documentation.

Ran unit tests and integration-tests

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/ameybarve15/geode-native feature/GEODE-2763

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode-native/pull/90.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #90


commit 41882663a30f44f1ce9d12235802768e932945b2
Author: Amey Barve 
Date:   2017-04-11T09:50:02Z

GEODE-2763: Remove of nonSingleHopsCount stat in client from  1. source
2. cpp and csharp unit tests 3. documentation.

commit 15705e9cab99b030d9e45ae618b6aad9084c5cd9
Author: Amey Barve 
Date:   2017-04-13T05:50:00Z

Merge branch 'develop' of https://github.com/apache/geode-native into 
feature/GEODE-2763




> Remove of nonSingleHopsCount stat in client
> ---
>
> Key: GEODE-2763
> URL: https://issues.apache.org/jira/browse/GEODE-2763
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Michael Dodge
>Assignee: Amey Barve
>
> A pre-existing issue (GEODE-2017) required the removal of the 
> nonSingleHopsCount statistic in the clients. Whilst marked for the native 
> client as well, it was not addressed in the native client. It should be.



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


[GitHub] geode-native issue #90: GEODE-2763: Remove of nonSingleHopsCount stat in cli...

2017-04-13 Thread echobravopapa
Github user echobravopapa commented on the issue:

https://github.com/apache/geode-native/pull/90
  
@ameybarve15 would you please squash your commits, TIA


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2763) Remove of nonSingleHopsCount stat in client

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2763:
---

Github user echobravopapa commented on the issue:

https://github.com/apache/geode-native/pull/90
  
@ameybarve15 would you please squash your commits, TIA


> Remove of nonSingleHopsCount stat in client
> ---
>
> Key: GEODE-2763
> URL: https://issues.apache.org/jira/browse/GEODE-2763
> Project: Geode
>  Issue Type: Bug
>  Components: docs, native client
>Reporter: Michael Dodge
>Assignee: Amey Barve
>
> A pre-existing issue (GEODE-2017) required the removal of the 
> nonSingleHopsCount statistic in the clients. Whilst marked for the native 
> client as well, it was not addressed in the native client. It should be.



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


Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jinmei Liao

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/#review171878
---




geode-core/build.gradle
Lines 116 (patched)


put the version number in the dependency-versions.properties



geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java
Lines 155 (patched)


the other 2 methods are hasValidJarContent, maybe make this to be the same 
name as well?



geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java
Lines 368 (patched)


since we logs the entire stack trace of the exception, we know the exact 
caues of the problem anyway, can we collapse those catch blocks?



geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java
Line 48 (original), 54 (patched)


If they only refer to empty string now, can we just get rid of them?



geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
Lines 81 (patched)


you can use:

extLibsDir = temporaryFolder.newFolder("ext");

It makes sure the dir is created too.



geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java
Lines 27 (patched)


by checking in this suite, would it cause the tests to be run twice?



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
Lines 250 (patched)


after you do an execute, gfshConnector.getGfshOutput() will always give you 
the last result string printed out in gfsh. 
you don't need commandResultToString method here, I believe.


- Jinmei Liao


On April 12, 2017, 6:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58393/
> ---
> 
> (Updated April 12, 2017, 6:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2686: Remove JarClassLoader
> - Remove JarClassLoader
> - Replace ClassPathLoader's collection of JarClassLoaders with a single 
> URLClassLoader
> - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
> 'myJar.v1.jar'
> 
> GEODE-2705: Jars undeployed from cluster configuration will not be loaded 
> from disk on member restart
> 
> GEODE-2686: Add more logging to JarDeployer
> 
> GEODE-2290: Limit scanning of deployed jars
> - Uses fast-classpath-scanner to scan jars for classes containing Functions 
> without eagerly loading all classes in the jar.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 304a1c4d7ede5b82299c8a0f05038f3d11b2ac82 
>   geode-assembly/src/test/resources/expected_jars.txt 
> b7d1dc22fd7995e6f7786984994ce62e1064bed3 
>   geode-core/build.gradle 757599a9d76844dec17e545d1b4d19b32c22afef 
>   geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
> 9ab7c308579c9ea5c8fb300ee7550b3153507b1c 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java
>  f4f40692d1574bb9eca9bf8f7d42ce64fab18f9b 
>   geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
> 9cd05899898fc82eec87a3f0ab5ace31b67ef308 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
> 18d4b42213f29761792d35f12eddfb1cbfbba081 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  f904af188eb295f1cb84e41023de168c160ed07f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  08f916b117a07ed303638366c64a2c9d5b807b91 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
>  d052551d85e5b01b16255160f76795e829a14429 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
>  5f1f16167e08dd79b299c42541fb01ee2546 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
>  8df24dbe35a08173932776226c9f20665db5e9a3 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
>  3f0508270b51b4930c2eafe15547b9b258b96bd9 
>   
> geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
>  c52d5754792cfeaed1bb87bdb9380a360308395a 
>   geode-core/src/test/java/org/apache/geode/inte

[jira] [Commented] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2773:


Commit 796c15ec5894c64a713633f5912078b827859691 in geode's branch 
refs/heads/develop from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=796c15e ]

GEODE-2773: Fix assertion error in the test.


> AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
> ---
>
> Key: GEODE-2773
> URL: https://issues.apache.org/jira/browse/GEODE-2773
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Though the test is passing, the following Assertion was thrown in one of the 
> VM.invokeAysc call.
> {noformat}
> [vm0] [info 2017/04/11 16:42:03.214 PDT  
> tid=72] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: expected:<5> but was:<6>
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at org.junit.Assert.failNotEquals(Assert.java:834)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:645)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:631)
> [vm0] at 
> org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
> [vm0] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [vm0] at java.lang.Thread.run(Thread.java:745)
> [vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
> args on object: "destroy key5" (took 682 ms)
> {noformat}



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


[GitHub] geode pull request #450: GEODE-2632: create ClientCachePutBench

2017-04-13 Thread kirklund
Github user kirklund commented on a diff in the pull request:

https://github.com/apache/geode/pull/450#discussion_r111432477
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+
+  this.temporaryFolder.create();
+  this.serverDirectory = this.temporaryFolder.getRoot();
+
+  startServerProcess();
+
+  try {
+startProcessReaders();
+
+ServerLauncher serverLauncher = new Serve

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2632:
---

Github user kirklund commented on a diff in the pull request:

https://github.com/apache/geode/pull/450#discussion_r111432477
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+
+ 

[jira] [Resolved] (GEODE-1912) gfsh does not validate start server command

2017-04-13 Thread Jinmei Liao (JIRA)

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

Jinmei Liao resolved GEODE-1912.

Resolution: Duplicate

> gfsh does not validate start server command
> ---
>
> Key: GEODE-1912
> URL: https://issues.apache.org/jira/browse/GEODE-1912
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Minor
>
> When I tried to start a server from gfsh I accidently used {{--locator}} 
> (singular) rather than -{{-locators}}. gfsh did not throw an error and 
> started the server without connecting to the locator.
> We should throw an error for unrecognized command options in gfsh.



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


[jira] [Resolved] (GEODE-2765) gfsh help should consistently use log4j log levels

2017-04-13 Thread Kirk Lund (JIRA)

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

Kirk Lund resolved GEODE-2765.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh help should consistently use log4j log levels
> --
>
> Key: GEODE-2765
> URL: https://issues.apache.org/jira/browse/GEODE-2765
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.2.0
>
>
> The fix for GEODE-2634 changed the gfsh commands that use --log-level option 
> to use log4j2 log levels. The gfsh help text needs to also change.



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


Jenkins build is back to normal : Geode-nightly #806

2017-04-13 Thread Apache Jenkins Server
See 




[jira] [Assigned] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

2017-04-13 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller reassigned GEODE-2777:
--

Assignee: Karen Smoler Miller

> Change version number from 1.1 to 1.2 in docs
> -
>
> Key: GEODE-2777
> URL: https://issues.apache.org/jira/browse/GEODE-2777
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
> `geode-docs` and `geode-book` directories.
> In the `geode-book` directory, make sure to change the hrefs in the subnav 
> from `/11/` to `/12/` and make relevant version changes to the `config.yml` 
> file.



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


[jira] [Commented] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

2017-04-13 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller commented on GEODE-2777:


This task is to be completed before a 1.2 release candidate is made.

> Change version number from 1.1 to 1.2 in docs
> -
>
> Key: GEODE-2777
> URL: https://issues.apache.org/jira/browse/GEODE-2777
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
> `geode-docs` and `geode-book` directories.
> In the `geode-book` directory, make sure to change the hrefs in the subnav 
> from `/11/` to `/12/` and make relevant version changes to the `config.yml` 
> file.



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


flakyTest on Jenkins

2017-04-13 Thread Anthony Baker
Previously we discussed splitting out the ‘flakyTest’ target into a separate 
Jenkins job [1].  You can see the results here [2].  

Here’s the job configuration:

- Exec: `docker run --rm -v $PWD:/geode -w /geode openjdk:8 bash ./gradlew 
flakyTest`
- JUnit results:  **/build/test-reports-flaky/*.xml
- Run nightly, timeout after 3h
- Run on 'ubuntu && !cloud-slave’ machines

Please let me know if you have any feedback.

Once the flakyTest job seems to be running smoothly (ahem), I’ll update the 
nightly job to run under docker and skip the flakyTest target.

Thanks,
Anthony

[1] 
http://mail-archives.apache.org/mod_mbox/geode-dev/201703.mbox/%3ccajrng03pthr7utkfs+nqxau3kn51m-clb6m8gtzo9_bh0zl...@mail.gmail.com%3e
 

[2] https://builds.apache.org/job/Geode-flakyTest/ 




[jira] [Updated] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

2017-04-13 Thread Eric Shu (JIRA)

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

Eric Shu updated GEODE-2773:

Fix Version/s: 1.2.0

> AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
> ---
>
> Key: GEODE-2773
> URL: https://issues.apache.org/jira/browse/GEODE-2773
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> Though the test is passing, the following Assertion was thrown in one of the 
> VM.invokeAysc call.
> {noformat}
> [vm0] [info 2017/04/11 16:42:03.214 PDT  
> tid=72] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: expected:<5> but was:<6>
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at org.junit.Assert.failNotEquals(Assert.java:834)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:645)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:631)
> [vm0] at 
> org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
> [vm0] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [vm0] at java.lang.Thread.run(Thread.java:745)
> [vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
> args on object: "destroy key5" (took 682 ms)
> {noformat}



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


Re: Review Request 58397: check off-heap limit during disk recovery

2017-04-13 Thread Eric Shu

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58397/#review171896
---


Ship it!




Ship It!

- Eric Shu


On April 12, 2017, 11:42 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58397/
> ---
> 
> (Updated April 12, 2017, 11:42 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Eric Shu, and Lynn Gallinat.
> 
> 
> Bugs: GEODE-2097
> https://issues.apache.org/jira/browse/GEODE-2097
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> During disk recovery, the code now checks the offheap LRU limit instead of 
> the heap LRU limit for offheap regions.
> A unit test has been added that without this fix would run out of offheap 
> memory during recovery.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
>  328ff35b940239bfbcf817d144d97f886506b33a 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java
>  eaababaf6be6041c72156a338c69fa81f10db4c5 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> d0aacc2d95fa38b1bc9faf68de795af5ef3d9090 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PlaceHolderDiskRegion.java
>  db01162aeeba8113c208565d683e71a41d0f6d00 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ProxyRegionMap.java 
> 92c7b6f8e90a3382e7ce00064581d69f9706fcd3 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/control/HeapMemoryMonitor.java
>  afc9a23aafba2c1f993b30546f24cd2b5d6a0126 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/control/InternalResourceManager.java
>  d16cd98bbb3eefc785a22f41441c1490060d0781 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/control/MemoryMonitor.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/control/OffHeapMemoryMonitor.java
>  414036747a5062ab556b60cdb58c5ce490312c78 
>   geode-core/src/main/java/org/apache/geode/internal/cache/lru/EnableLRU.java 
> 6aaf8cc914c3b8c2e308446930bbd3215c9f58ca 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/HeapLRUCapacityController.java
>  5e86ce87b99fc4e8793461e881853c141fdfec1f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUCapacityController.java
>  3596a07df407960c3558057ac33e92c89bd5ba22 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/LRUMapCallbacks.java
>  27a4ec019ae3b5fd29a26ffc451d0d9feb75f903 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/lru/MemLRUCapacityController.java
>  2c2e8ec1a805b7485e6e59858a12122fa8d88de1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/lru/LRUClockJUnitTest.java
>  8095d5ac483be061199623a78b63618697e09d9d 
>   
> geode-core/src/test/java/org/apache/geode/internal/offheap/OffHeapLRURecoveryRegressionTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/58397/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>



[jira] [Updated] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

2017-04-13 Thread Galen O'Sullivan (JIRA)

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

Galen O'Sullivan updated GEODE-2746:

Description: 
There are several existing RPC frameworks for which you can define the 
structure of your protocol and the tool will generate code for talking over the 
wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design 
our own binary protocol. This protocol would define both what kind of messages 
can be sent and how they are encoded on the wire. How we encode the objects 
that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]
* [Avro|https://avro.apache.org/]

These are two not-entirely-common features we will need to have:
* support for SSL/TLS, ability to connect to a server with IP & port.
* support for push messages from the server without polling (this is needed for 
CQs).

This is one half of GEODE-2734.

  was:
There are several existing RPC frameworks for which you can define the 
structure of your protocol and the tool will generate code for talking over the 
wire, generally down to serialization of objects.

If one of those RPC frameworks does not fit all our requirements, we'll design 
our own binary protocol. This protocol would define both what kind of messages 
can be sent and how they are encoded on the wire. How we encode the objects 
that we are sending in requests, however, could still be pluggable.

A few contenders:
* [BERT|http://bert-rpc.org]
* [thrift|https://thrift.apache.org/]
* [gRPC|http://www.grpc.io/]

These are two not-entirely-common features we will need to have:
* support for SSL/TLS, ability to connect to a server with IP & port.
* support for push messages from the server without polling (this is needed for 
CQs).

This is one half of GEODE-2734.


> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> * [Avro|https://avro.apache.org/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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


[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

2017-04-13 Thread Galen O'Sullivan (JIRA)

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

Galen O'Sullivan commented on GEODE-2746:
-

gRPC has some issues if we send a whole lot of messages in a stream back to the 
client, where Netty gets OOM due to a lack of backpressure. It's not quite out 
but it would take work to make it work.

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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


[jira] [Updated] (GEODE-2778) gfsh help now uses log4j log levels: update user guide

2017-04-13 Thread Dave Barnes (JIRA)

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

Dave Barnes updated GEODE-2778:
---
Component/s: docs

> gfsh help now uses log4j log levels: update user guide
> --
>
> Key: GEODE-2778
> URL: https://issues.apache.org/jira/browse/GEODE-2778
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Dave Barnes
> Fix For: 1.2.0
>
>
> Update the user guide to reflect this change.



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


[jira] [Assigned] (GEODE-2778) gfsh help now uses log4j log levels: update user guide

2017-04-13 Thread Dave Barnes (JIRA)

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

Dave Barnes reassigned GEODE-2778:
--

Assignee: Dave Barnes

> gfsh help now uses log4j log levels: update user guide
> --
>
> Key: GEODE-2778
> URL: https://issues.apache.org/jira/browse/GEODE-2778
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs, gfsh
>Reporter: Dave Barnes
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> Update the user guide to reflect this change.



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


[jira] [Created] (GEODE-2778) gfsh help now uses log4j log levels: update user guide

2017-04-13 Thread Dave Barnes (JIRA)
Dave Barnes created GEODE-2778:
--

 Summary: gfsh help now uses log4j log levels: update user guide
 Key: GEODE-2778
 URL: https://issues.apache.org/jira/browse/GEODE-2778
 Project: Geode
  Issue Type: Sub-task
Reporter: Dave Barnes


Update the user guide to reflect this change.



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


Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Ken Howe

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171900
---


Fix it, then Ship it!




Ship It!


geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
Line 55 (original), 55 (patched)


Hate to say this after you made the change, but seeing it fully implemented 
I think I'd prefer something like autoStart, and method renamed to 
withAutoStart(). That would be more consistent with the other chained 
configuration methods, 'with...()'.



geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
Line 110 (original), 110 (patched)


Rename withAutoStart() ?


- Ken Howe


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> geode-core/src/test/java/org/apac

[jira] [Commented] (GEODE-2694) RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the recovered entry and gii entry has the same version tag

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2694:


Commit 60a96cc2b809ad28a21ac41e54f795274060fa04 in geode's branch 
refs/heads/feature/GEODE-2632 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=60a96cc ]

GEODE-2694: Add test coverage on RECOVERED_FROM_DISK bit after gii.


> RECOVERED_FROM_DISK bit is cleared during gii, but should be restored if the 
> recovered entry and gii entry has the same version tag
> ---
>
> Key: GEODE-2694
> URL: https://issues.apache.org/jira/browse/GEODE-2694
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Eric Shu
>Assignee: Eric Shu
>
> Currently for all gii entries, product clears the RECOVERED_FROM_DISK bit for 
> DiskEntry. However, if entry comes from gii has the same version as recovered 
> entry, the RECOVERED_FROM_DISK bit should be restored but does not.
> {noformat}
> synchronized (re) { // fixes bug 41409
>   if (dr.testIsRecoveredAndClear(re)) {
> wasRecovered = true;
> if (tmpValue == null) {
>   tmpValue = entry.isLocalInvalid() ? Token.LOCAL_INVALID : 
> Token.INVALID;
> }
> // Compare the version stamps, and if they are equal
> // we can skip adding the entry we receive as part of GII.
> VersionStamp stamp = re.getVersionStamp();
> boolean entriesEqual = stamp != null && 
> stamp.asVersionTag().equals(tag);
> // If the received entry and what we have in the cache
> // actually are equal, keep don't put the received
> // entry into the cache (this avoids writing a record to disk)
> if (entriesEqual) {
>   continue;
> }
> {noformat}



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


[jira] [Commented] (GEODE-2745) The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should for events to be flushed

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2745:


Commit f13da788c8b2d2315581c451154f8e5410b764bc in geode's branch 
refs/heads/feature/GEODE-2632 from [~lhughesgodfrey]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f13da78 ]

GEODE-2745: waitUntilFlushed method waits longer than it should

- Added getter in BucketRegionQueue for latestQueuedKey
- WaitUntilBucketRegionQueueFlushedCallable constructor now gets/maintains the 
BucketRegionQueue.latestQueuedKey


> The AsyncEventQueueImpl waitUntilFlushed method waits longer than it should 
> for events to be flushed
> 
>
> Key: GEODE-2745
> URL: https://issues.apache.org/jira/browse/GEODE-2745
> Project: Geode
>  Issue Type: Bug
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> With the changes to waitUntilFlushed to process 10 buckets at a time, if 
> events are happening while waitUntilFlushed is in progress, then all the 
> buckets after the first 10 will have processed more than it should before 
> returning.
> If the update rate is causing the queue to always contain 113000 events, and 
> the events are spread evenly across the buckets, each bucket will have 1000 
> events to wait for. The first 10 buckets will wait for their 1000 events. 
> When those have been processed, the next 10 buckets will wait for their 1000 
> events starting from that point, but they've already processed 1000 events. 
> So, these buckets will actually wait for 2000 events to be processed before 
> returning. This pattern continues until all the buckets are done.
> The WaitUntilBucketRegionQueueFlushedCallable needs to track not only the 
> BucketRegionQueue but also the latestQueuedKey.



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


[jira] [Commented] (GEODE-2725) export logs does not honor --dir

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2725:


Commit 122e65058f643d8ac862398e5baeba59c2628d8c in geode's branch 
refs/heads/feature/GEODE-2632 from [~prhomberg]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=122e650 ]

GEODE-2725: export logs now honors --dir when connected via JMX, with
respect to the manager filesystem.

* Absolute Paths are better.  Test class inheritance is cumbersome.

* Removed --dir usage from ExportLogsDUnitTests:
startAndEndDateCanIncludeLogs and
testExportWithStartAndEndDateTimeFiltering; these tests expected logs
to appear in the locator working directory and the --dir option was
not actually being used.

* Usage of LocalLocatorStarterRules reverted in
ExportLogsIntegrationTest as locator working directory access is
required.

* this closes #438

Corrected mismatched merging of strings against offline help golden file.


> export logs does not honor --dir
> 
>
> Key: GEODE-2725
> URL: https://issues.apache.org/jira/browse/GEODE-2725
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, logging
>Reporter: Swapnil Bawaskar
>Assignee: Patrick Rhomberg
>
> When connected to locator via jmx, run the following command:
> {noformat}
> gfsh>export logs --dir=tmp
> {noformat}
> Observer that the dir option is ignored:
> {noformat}
> Logs exported to the connected member's file system: 
> /Users/sbawaskar/apache/geode/geode-assembly/build/install/apache-geode/loc1/exportedLogs_1490721273215.zip
> {noformat}
> The --tmp option is honored when connected via http.



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


[jira] [Commented] (GEODE-2737) PulseAuthTest failures

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2737:


Commit 3a64b57ce433c7ed7ed0923af0d3c5811d0d4169 in geode's branch 
refs/heads/feature/GEODE-2632 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3a64b57 ]

GEODE-2737: Change Pulse UI tests to use random port for JMX connections

Renamed parameter port to jmxPort in Server.java to clarify usage.


> PulseAuthTest failures
> --
>
> Key: GEODE-2737
> URL: https://issues.apache.org/jira/browse/GEODE-2737
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
> Fix For: 1.2.0
>
>
> Tests are failing in the PulseAuthTest (UITest category) with the error:
> {code}
> org.apache.geode.tools.pulse.tests.ui.PulseAuthTest > testTopologyPopUpData 
> FAILED
> org.openqa.selenium.TimeoutException: Expected condition failed: waiting 
> for org.apache.geode.tools.pulse.tests.rules.WebDriverRule$1@4d7af88e (tried 
> for 30 second(s) with 500 MILLISECONDS interval)
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', os.name: 
> 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> Caused by:
> org.openqa.selenium.NoSuchElementException: {"errorMessage":"Unable 
> to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"33","Content-Type":"application/json;
>  
> charset=utf-8","Host":"localhost:43794","User-Agent":"Apache-HttpClient/4.5.2 
> (Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"using\":\"id\",\"value\":\"userName\"}","url":"/element","urlParsed":{"anchor":"","query":"","file":"element","directory":"/","path":"/element","relative":"/element","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/element","queryKey":{},"chunks":["element"]},"urlOriginal":"/session/abd2bc60-1593-11e7-922e-d790ba7a8581/element"}}
> Command duration or timeout: 10.13 seconds
> For documentation on this error, please visit: 
> http://seleniumhq.org/exceptions/no_such_element.html
> Build info: version: '3.0.1', revision: '1969d75', time: '2016-10-18 
> 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false, 
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=MAC, 
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true, 
> acceptSslCerts=false, driverVersion=1.2.0, 
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64; 
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false, 
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true, 
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: abd2bc60-1593-11e7-922e-d790ba7a8581
> *** Element info: {Using=id, value=userName}
> Caused by:
> org.openqa.selenium.remote.ScreenshotException: Screen shot has 
> been taken
> Build info: version: '3.0.1', revision: '1969d75', time: 
> '2016-10-18 09:49:13 -0700'
> System info: host: 'Kens-MacBook-Pro-2.local', ip: '127.0.0.1', 
> os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.12.3', java.version: 
> '1.8.0_111'
> Driver info: driver.version: RemoteWebDriver
> Caused by:
> org.openqa.selenium.NoSuchElementException: 
> {"errorMessage":"Unable to find element with id 
> 'userName'","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection

[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-1577:


Commit 4816d39402bf1b2d0ed7ea347695b2aef46a45cb in geode's branch 
refs/heads/feature/GEODE-2632 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4816d39 ]

 GEODE-1577: Unhelpful generic types on Execution.execute

  * Replaced wildcards with  for non-deprecated Execution.execute methods.
  * descriptions added for params  in javadoc
  * explicit type casting removed
  * This closes #321


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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


[jira] [Commented] (GEODE-1577) Unhelpful generic types on Execution.execute

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-1577:


Commit bd40bcac75aa61b128849d68b88cd8df08b40f3e in geode's branch 
refs/heads/feature/GEODE-2632 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bd40bca ]

GEODE-1577: modified MultiRegionFunctionExecutor to fix compilation error


> Unhelpful generic types on Execution.execute
> 
>
> Key: GEODE-1577
> URL: https://issues.apache.org/jira/browse/GEODE-1577
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Dan Smith
>
> The execute methods of the function service Execution class returns a 
> ResultCollector with wildcards for the type.
> {code}  
> public ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> Wildcards are supposed to be used in APIs where the type doesn't matter, for 
> example counting the elements in a list. By returning a ResultCollector with 
> wildcards, we're essentially forcing the user to cast the result collector.
> At a minimum they should be able to pick the type of result collector
> {code}
>   public  ResultCollector execute(
>   Function function) throws FunctionException;
> {code}
> But maybe it would make more sense to parameterize Execution itself. Then the 
> compiler could ensure that the types used by withCollector and the types used 
> by execute match.



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


Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Jinmei Liao


> On April 13, 2017, 5:08 p.m., Ken Howe wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
> > Line 110 (original), 110 (patched)
> > 
> >
> > Rename withAutoStart() ?

yeah, I like this name too.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171900
---


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
>  1661cc8d5ba42b782e08251338605c001c526c97 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/QueryUtilsJUnitTest.java
>  85305560669544d5fb3493a88f7bf93d86b8ac91 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/IndexMaintenanceJUnitTe

[jira] [Commented] (GEODE-2217) Add generic type parameter to FunctionContext interface

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2217:


Commit bc2218409cfe2693e3bb886ee1660c7ab4748323 in geode's branch 
refs/heads/feature/GEODE-2632 from [~dalyssakim]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=bc22184 ]

GEODE-2217: Add generic type parameter to FunctionContext interface

 * This closes #447


> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



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


[jira] [Commented] (GEODE-2773) AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2773:


Commit 796c15ec5894c64a713633f5912078b827859691 in geode's branch 
refs/heads/feature/GEODE-2632 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=796c15e ]

GEODE-2773: Fix assertion error in the test.


> AssertionError shown in GIIDeltaDUnitTest.testFullGIITriggeredByHigherRVVGC
> ---
>
> Key: GEODE-2773
> URL: https://issues.apache.org/jira/browse/GEODE-2773
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Eric Shu
>Assignee: Eric Shu
> Fix For: 1.2.0
>
>
> Though the test is passing, the following Assertion was thrown in one of the 
> VM.invokeAysc call.
> {noformat}
> [vm0] [info 2017/04/11 16:42:03.214 PDT  
> tid=72] Got result: EXCEPTION_OCCURRED
> [vm0] java.lang.AssertionError: expected:<5> but was:<6>
> [vm0] at org.junit.Assert.fail(Assert.java:88)
> [vm0] at org.junit.Assert.failNotEquals(Assert.java:834)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:645)
> [vm0] at org.junit.Assert.assertEquals(Assert.java:631)
> [vm0] at 
> org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run(GIIDeltaDUnitTest.java:2587)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at 
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:73)
> [vm0] at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> [vm0] at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at 
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:324)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm0] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm0] at java.security.AccessController.doPrivileged(Native Method)
> [vm0] at 
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [vm0] at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [vm0] at java.lang.Thread.run(Thread.java:745)
> [vm0]  from org.apache.geode.internal.cache.GIIDeltaDUnitTest$55.run with 0 
> args on object: "destroy key5" (took 682 ms)
> {noformat}



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


[jira] [Commented] (GEODE-2193) a member is kicked out immediately after joining

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2193:


Commit c9b036b40d3eed0028629d6e90c833da96063986 in geode's branch 
refs/heads/feature/GEODE-2632 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c9b036b ]

GEODE-2193 Now we don't send view if shutdown process is started.

Earlier we were checking flag, which was set after sending the shutdown
message. Now we check flag, which was set before sending the shutdown
message.


> a member is kicked out immediately after joining
> 
>
> Key: GEODE-2193
> URL: https://issues.apache.org/jira/browse/GEODE-2193
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> We have observed a number of cases where a member is kicked out immediately 
> after joining.  The problem seems to be this:
> 1) the member sends a join request to the current coordinator
> 2) the current coordinator is in the process of shutting down
> 3) the current coordinator sends a view preparation message admitting the new 
> member
> 4) another member receives the current coordinator's shutdown message and 
> initiates becoming the coordinator
> 5) the new coordinator sends out a membership view that does not include the 
> new member
> 6) the new member receives the prepared view and continues with startup
> 7) the new member sends startup messages to other members
> 8) the other members have the new coordinator's view and request removal of 
> the new member as being rogue
> 9) the new coordinator sends a Leave message to the new member, causing it to 
> issue a ForcedDisconnect
> The old coordinator should not initiate a new view if it is shutting down.  
> It needs to have cancellation & shutdown checks in its view transmission 
> methods.



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


[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

2017-04-13 Thread Avinash Dongre (JIRA)

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

Avinash Dongre commented on GEODE-2746:
---

When I was trying out gRPC, I also faced the same problem. One need to use 
ServerCallStreamObserver and ServerCallStreamObserver.setOnReadyHandler, when 
you have lot of message in case of stream. ( 
https://github.com/davinash/grpc-bench)

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> * [Avro|https://avro.apache.org/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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


[jira] [Commented] (GEODE-2730) Refactor ServerStarterRule and LocatorStarterRule

2017-04-13 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2730:


Commit 6a88f1bcce2ef09a814a6f7545896cc4f0c26da7 in geode's branch 
refs/heads/develop from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=6a88f1b ]

GEODE-2730: refactor rules

* consolidate the two sets of server/locator starter rules
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before


> Refactor ServerStarterRule and LocatorStarterRule
> -
>
> Key: GEODE-2730
> URL: https://issues.apache.org/jira/browse/GEODE-2730
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Right now many tests that use ServerStarterRule and LocatorStarterRule are 
> flaky due to relying on default ports that intermittently cause 
> BindExceptions when those ports are in use. They also do not consistently use 
> the @Rule lifecycle to manage starting the member, but can optionally start 
> members when the rule is instantiated.



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


[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

2017-04-13 Thread davinash
Github user davinash commented on the issue:

https://github.com/apache/geode/pull/450
  
+1. @kirklund what is correct way of running those benchmark. Is following 
command correct 
./gradlew :geode-core:jmh


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2632:
---

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/450
  
+1. @kirklund what is correct way of running those benchmark. Is following 
command correct 
./gradlew :geode-core:jmh


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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


Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Kirk Lund
If I google for something like "apache geode pulse Log-File-Location" then
the top few search results are broken. Is this expected or temporary?

https://geode.apache.org/docs/guide/configuring/running/running_the_locator.html

Not Found
The requested URL /docs/guide/configuring/running/running_the_locator.html
was not found on this server.

https://geode.apache.org/docs/guide/configuring/running/running_the_cacheserver.html

Not Found
The requested URL
/docs/guide/configuring/running/running_the_cacheserver.html was not found
on this server.

https://geode.apache.org/docs/guide/tools_modules/gfsh/configuring_gfsh.html

Not Found
The requested URL /docs/guide/tools_modules/gfsh/configuring_gfsh.html was
not found on this server.




[GitHub] geode pull request #453: GEODE-2777 Update docs to be for Geode version 1.2

2017-04-13 Thread karensmolermiller
GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/453

GEODE-2777 Update docs to be for Geode version 1.2

This PR only addresses doc changes in the Apache geode repository.  Any 
website changes related to releasing a 1.2 version of Geode will need to be 
done in a separate PR, and on the geode-site repository.

@joeymcallister @davebarnes97 and any other Geode afficionados, will you 
please review this PR?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-2777

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/453.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #453


commit 152509797c437f1c7063d0583435d2f0d93b521f
Author: Karen Miller 
Date:   2017-04-13T17:17:21Z

GEODE-2777 Update docs to be for Geode version 1.2




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2777:
---

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/geode/pull/453

GEODE-2777 Update docs to be for Geode version 1.2

This PR only addresses doc changes in the Apache geode repository.  Any 
website changes related to releasing a 1.2 version of Geode will need to be 
done in a separate PR, and on the geode-site repository.

@joeymcallister @davebarnes97 and any other Geode afficionados, will you 
please review this PR?

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/karensmolermiller/geode feature/GEODE-2777

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/453.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #453


commit 152509797c437f1c7063d0583435d2f0d93b521f
Author: Karen Miller 
Date:   2017-04-13T17:17:21Z

GEODE-2777 Update docs to be for Geode version 1.2




> Change version number from 1.1 to 1.2 in docs
> -
>
> Key: GEODE-2777
> URL: https://issues.apache.org/jira/browse/GEODE-2777
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
> `geode-docs` and `geode-book` directories.
> In the `geode-book` directory, make sure to change the hrefs in the subnav 
> from `/11/` to `/12/` and make relevant version changes to the `config.yml` 
> file.



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


[GitHub] geode issue #450: GEODE-2632: create ClientCachePutBench

2017-04-13 Thread kirklund
Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
@davinash I'm using "$ ./gradlew geode-core:jmh"


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2632:
---

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/450
  
@davinash I'm using "$ ./gradlew geode-core:jmh"


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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


Re: flakyTest on Jenkins

2017-04-13 Thread Kirk Lund
Looks great. Thanks!

On Thu, Apr 13, 2017 at 9:52 AM, Anthony Baker  wrote:

> Previously we discussed splitting out the ‘flakyTest’ target into a
> separate Jenkins job [1].  You can see the results here [2].
>
> Here’s the job configuration:
>
> - Exec: `docker run --rm -v $PWD:/geode -w /geode openjdk:8 bash ./gradlew
> flakyTest`
> - JUnit results:  **/build/test-reports-flaky/*.xml
> - Run nightly, timeout after 3h
> - Run on 'ubuntu && !cloud-slave’ machines
>
> Please let me know if you have any feedback.
>
> Once the flakyTest job seems to be running smoothly (ahem), I’ll update
> the nightly job to run under docker and skip the flakyTest target.
>
> Thanks,
> Anthony
>
> [1] http://mail-archives.apache.org/mod_mbox/geode-dev/201703.
> mbox/%3cCAJrNg03PThr7UtkFS+NQXau3KN51m-CLB6M8gtZO9_
> bh0zl...@mail.gmail.com%3e  org/mod_mbox/geode-dev/201703.mbox/%3CCAJrNg03PThr7UtkFS+
> nqxau3kn51m-clb6m8gtzo9_bh0zl...@mail.gmail.com%3E>
> [2] https://builds.apache.org/job/Geode-flakyTest/ <
> https://builds.apache.org/job/Geode-flakyTest/>
>
>


Re: Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Michael Stolz
On further inspection, this is due to the versioning that was added in
/docs/guide.
There is now a /docs/guide/10 and a /docs/guide/11 each of which contains a
"configuring" folder a "tools_modules" folder, etc.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Thu, Apr 13, 2017 at 1:40 PM, Kirk Lund  wrote:

> If I google for something like "apache geode pulse Log-File-Location" then
> the top few search results are broken. Is this expected or temporary?
>
> https://geode.apache.org/docs/guide/configuring/running/
> running_the_locator.html
>
> Not Found
> The requested URL /docs/guide/configuring/running/running_the_locator.html
> was not found on this server.
>
> https://geode.apache.org/docs/guide/configuring/running/
> running_the_cacheserver.html
>
> Not Found
> The requested URL
> /docs/guide/configuring/running/running_the_cacheserver.html was not found
> on this server.
>
> https://geode.apache.org/docs/guide/tools_modules/gfsh/
> configuring_gfsh.html
>
> Not Found
> The requested URL /docs/guide/tools_modules/gfsh/configuring_gfsh.html was
> not found on this server.
>
> 
>


Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Kirk Lund

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/#review171910
---




geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 55 (patched)


We should fix these on Windows or use org.junit.Assume to prevent running 
these tests on that OS:
```java
@Test
public void myTest() throws Exception {
  assumeFalse(SystemUtils.isWindows());
  ...
}
```



geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 65 (patched)


In general, I would recommend moving the setting of vars like this into 
setup() so you can see all test state centralized in setup().



geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 104 (patched)


Delete all try-catch blocks from these tests. Let JUnit deal with them.



geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 122 (patched)


Replace all try-fail-catch patterns with AssertJ's assertThatThrownBy or 
Catch-Exception (I prefer AssertJ).



geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 367 (patched)


Change all test method signatures to throws Exception and delete all 
try-catch structures for unexpected Exceptions.



geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java
Lines 500 (patched)


I think I reviewed this code previously with some additional tips on using 
Executor instead of Thread and getting rid of all try-catch blocks.



geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
Lines 97 (patched)


One more variable for the next two changes:
```java
volatile isJarDeployed = false;
```



geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
Line 130 (original), 112 (patched)


Insert another line here to set a boolean true which await() will test for 
a few lines later:
```java
isJarDeployed = true;
```



geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
Line 144 (original), 116 (patched)


Thread.sleep should be replaced with Awaitility:
```java
await().atMost(2, MINUTES).until(() -> assertThat(isJarDeployed).isTrue());

```



geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
Lines 1106 (patched)


Don't use Java assertions in tests. Change this to assertTrue or 
assertThat().isTrue.



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
Lines 47 (patched)


Recommend renaming these constants in UPPERCASE.



geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
Lines 115 (patched)


Recommend doing this in a test/resources file next time instead of 
concatenating Strings. I would still be good to consider moving this to a 
resource.



geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
Line 33 (original), 34 (patched)


I would change this class to abstract. Also rename to ClusterConfigTestBase 
or checkMissedTests gradle task is going to fail (or it should if it's 
implemented correctly).



geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
Lines 62 (patched)


You might want to consider changing this to a loop from zero to 
getHost(0).getVMCount(). It might be unlikely right now, but it's possible 
someone might write a DUnit test that executes before this test which expands 
the VMCount beyond the default 4 -- unless extra VMs won't impact these tests 
that extend this class?



geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
Line 38 (original), 40 (patched)


Having seen super.setUp() abused in horrible ways, I recommend avoiding 
this at all costs. You already have a hint of this abuse in this example -- 
this  before bounces 3 VMs and th

Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Kirk Lund

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171919
---



I'm finding lots of instances where "withRegion" was changed to "createRegion" 
but it's an API or Util class that isn't related to your Rule changes. You 
probably don't want to change all of these instances of "withRegion" -- rather 
than keep flagging more of these, I'll send the review as is.


geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
Line 42 (original), 41 (patched)


Does server.getHttpPort() require that Rule before was already invoked on 
server? If so then we need RuleChain to guarantee ordering. If construcing 
ServerStarterRule provides a HttpPort, then it should be ok like this.



geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java
Line 5043 (original), 5043 (patched)


Can we just delete the dead code in this test?



geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java
Line 1034 (original), 1034 (patched)


Can we just delete the dead code in this test?



geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
Line 77 (original), 77 (patched)


Did you mean to make these changes? These are just the string names for the 
SerializableRunnables.



geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
Line 321 (original), 321 (patched)


This looks like someone defined a colocation API "withRegion" and may be an 
existing API on one of the Cache interfaces or the implementations. You 
probably don't want to change these instances of "withRegion"



geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
Line 524 (original), 524 (patched)


These are more instances of the withRegion API.



geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
Line 641 (original), 641 (patched)


Another withRegion API you probably don't want to change.


- Kirk Lund


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test

Re: Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Kirk Lund
The old URLs should probably redirect to the greatest version number then,
right?

Either way, we have broken URLs showing up at the top of our google
searches. There must be a way of telling Google to flush these out or
otherwise fix them.

On Thu, Apr 13, 2017 at 12:05 PM, Michael Stolz  wrote:

> On further inspection, this is due to the versioning that was added in
> /docs/guide.
> There is now a /docs/guide/10 and a /docs/guide/11 each of which contains a
> "configuring" folder a "tools_modules" folder, etc.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771
>
> On Thu, Apr 13, 2017 at 1:40 PM, Kirk Lund  wrote:
>
> > If I google for something like "apache geode pulse Log-File-Location"
> then
> > the top few search results are broken. Is this expected or temporary?
> >
> > https://geode.apache.org/docs/guide/configuring/running/
> > running_the_locator.html
> >
> > Not Found
> > The requested URL /docs/guide/configuring/running/running_the_locator.
> html
> > was not found on this server.
> >
> > https://geode.apache.org/docs/guide/configuring/running/
> > running_the_cacheserver.html
> >
> > Not Found
> > The requested URL
> > /docs/guide/configuring/running/running_the_cacheserver.html was not
> found
> > on this server.
> >
> > https://geode.apache.org/docs/guide/tools_modules/gfsh/
> > configuring_gfsh.html
> >
> > Not Found
> > The requested URL /docs/guide/tools_modules/gfsh/configuring_gfsh.html
> was
> > not found on this server.
> >
> > 
> >
>


Re: Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Swapnil Bawaskar
It's not just google, we also point users to the docs in forums, on user
list etc. So, these links should never be broken.
We put the javadocs, under "latest" for example
/releases/latest/javadoc/index.html, so the link always stays current. Can
we do something similar for the user guide as well?



On Thu, Apr 13, 2017 at 12:28 PM Kirk Lund  wrote:

> The old URLs should probably redirect to the greatest version number then,
> right?
>
> Either way, we have broken URLs showing up at the top of our google
> searches. There must be a way of telling Google to flush these out or
> otherwise fix them.
>
> On Thu, Apr 13, 2017 at 12:05 PM, Michael Stolz  wrote:
>
> > On further inspection, this is due to the versioning that was added in
> > /docs/guide.
> > There is now a /docs/guide/10 and a /docs/guide/11 each of which
> contains a
> > "configuring" folder a "tools_modules" folder, etc.
> >
> > --
> > Mike Stolz
> > Principal Engineer, GemFire Product Manager
> > Mobile: +1-631-835-4771 <(631)%20835-4771>
> >
> > On Thu, Apr 13, 2017 at 1:40 PM, Kirk Lund  wrote:
> >
> > > If I google for something like "apache geode pulse Log-File-Location"
> > then
> > > the top few search results are broken. Is this expected or temporary?
> > >
> > > https://geode.apache.org/docs/guide/configuring/running/
> > > running_the_locator.html
> > >
> > > Not Found
> > > The requested URL /docs/guide/configuring/running/running_the_locator.
> > html
> > > was not found on this server.
> > >
> > > https://geode.apache.org/docs/guide/configuring/running/
> > > running_the_cacheserver.html
> > >
> > > Not Found
> > > The requested URL
> > > /docs/guide/configuring/running/running_the_cacheserver.html was not
> > found
> > > on this server.
> > >
> > > https://geode.apache.org/docs/guide/tools_modules/gfsh/
> > > configuring_gfsh.html
> > >
> > > Not Found
> > > The requested URL /docs/guide/tools_modules/gfsh/configuring_gfsh.html
> > was
> > > not found on this server.
> > >
> > > 
> > >
> >
>


Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Jinmei Liao


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > I'm finding lots of instances where "withRegion" was changed to 
> > "createRegion" but it's an API or Util class that isn't related to your 
> > Rule changes. You probably don't want to change all of these instances of 
> > "withRegion" -- rather than keep flagging more of these, I'll send the 
> > review as is.

These were originally "createRegion". They were accidentally changed by Jared's 
regex in his last commit.


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
> > Line 42 (original), 41 (patched)
> > 
> >
> > Does server.getHttpPort() require that Rule before was already invoked 
> > on server? If so then we need RuleChain to guarantee ordering. If 
> > construcing ServerStarterRule provides a HttpPort, then it should be ok 
> > like this.

In this case, ordering does not matter, since the httpPort is initialized by 
the withJMXManager call in the variable declaration.


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java
> > Line 5043 (original), 5043 (patched)
> > 
> >
> > Can we just delete the dead code in this test?

again this was the code that I didn't touch. I am just simply reverting those 
changes.


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
> > Line 77 (original), 77 (patched)
> > 
> >
> > Did you mean to make these changes? These are just the string names for 
> > the SerializableRunnables.

I am only reverting Jared original commit, which should have changed these code 
before.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171919
---


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba8

[jira] [Comment Edited] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

2017-04-13 Thread Kirk Lund (JIRA)

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

Kirk Lund edited comment on GEODE-2775 at 4/13/17 7:46 PM:
---

The problem lies in the fact that when in the embedded mode, the useSSL flag of 
pulse is not correctly set. Here is the workaround with the current release:
In the embedded mode:
* once a locator/server is started with ssl, go to the working directory of the 
member and find the pulse.properties file. Change the property 
"pulse.useSSL.manager" to true. 
* restart the locator/server to pick up the change in the properties file, now 
pulse should be able to connect.

In the standalone mode:
* follow this guide to set up the pulse.properties and pulsesecurity.properties 
with the ssl information: 
https://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html
* remember to put "pulse.useSSL.manager=true" in the pulse.properties


was (Author: jinmeiliao):
The problem lies in the fact that when in the embedded mode, the useSSL flag of 
pulse is not correctly set. Here is the workaround with the current release:
In the embedded mode:
* once a locator/server is started with ssl, go to the working directory of the 
member and find the pulse.properties file. Change the property 
"pulse.useSSL.manager" to true. 
* restart the locator/server to pick up the change in the properties file, now 
pulse should be able to connect.

In the standalone mode:
* follow this guide to set up the pulse.properties and pulsesecurity.properties 
with the ssl information: 
http://gemfirexd.docs.pivotal.io/1.3.1/userguide/manage_guide/pulse/quickstart.html
* remember to put "pulse.useSSL.manager=true" in the pulse.properties

> Pulse is not using certificate to connect to JMX when ssl is turned for jmx 
> connection
> --
>
> Key: GEODE-2775
> URL: https://issues.apache.org/jira/browse/GEODE-2775
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.1
>Reporter: Jinmei Liao
>
> Steps to reproduce:
> 1) start a locator with a SecurityManager and with this property: 
> ssl-enabled-components=jmx
> 2) start a browser and tries to login to pulse.
> Actual result: not able to log in using valid username/password



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


Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Jinmei Liao


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
> > Line 77 (original), 77 (patched)
> > 
> >
> > Did you mean to make these changes? These are just the string names for 
> > the SerializableRunnables.
> 
> Jinmei Liao wrote:
> I am only reverting Jared original commit, which should have changed 
> these code before.

I meant "should not".


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
> > Line 321 (original), 321 (patched)
> > 
> >
> > This looks like someone defined a colocation API "withRegion" and may 
> > be an existing API on one of the Cache interfaces or the implementations. 
> > You probably don't want to change these instances of "withRegion"

No, those are changed by Jared's previous commit. he used a regex to replace 
"createRegion" with "withRegion", and caused these changes which should be have 
been there.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171919
---


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUn

[jira] [Reopened] (GEODE-2554) Geode incubator docs are still up

2017-04-13 Thread Joey McAllister (JIRA)

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

Joey McAllister reopened GEODE-2554:

  Assignee: Joey McAllister  (was: Dave Barnes)

Reopening to address redirects.

> Geode incubator docs are still up
> -
>
> Key: GEODE-2554
> URL: https://issues.apache.org/jira/browse/GEODE-2554
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Galen O'Sullivan
>Assignee: Joey McAllister
> Fix For: 1.2.0
>
>
> Search engines still direct users to the Geode incubating docs, which are at:
> https://geode.apache.org/docs/guide/basic_config/data_regions/managing_data_regions.html
> The most recent docs have an 11 in the URL:
> https://geode.apache.org/docs/guide/11/basic_config/data_regions/managing_data_regions.html
> The old docs should either be taken down, or the path made to refer to 
> whatever the latest docs are. That way visitors won't get stuck on an ever 
> increasingly stale docs site.



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


[jira] [Commented] (GEODE-2775) Pulse is not using certificate to connect to JMX when ssl is turned for jmx connection

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2775:
---

GitHub user PurelyApplied opened a pull request:

https://github.com/apache/geode/pull/454

GEODE-2775: Corrected setting of Pulse SSL Manager flag

Flag now set from System properties instead of pulse.properties when 
running in embedded mode.

Precheckin returned fully green.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PurelyApplied/geode geode-2775

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #454


commit 9748668b562963716cd8b6bb5d7aa87c6d40d414
Author: Patrick Rhomberg 
Date:   2017-04-12T18:39:11Z

GEODE-2775: Corrected setting of Pulse SSL Manager flag from System 
properties instead of pulse.properties when running in embedded mode.




> Pulse is not using certificate to connect to JMX when ssl is turned for jmx 
> connection
> --
>
> Key: GEODE-2775
> URL: https://issues.apache.org/jira/browse/GEODE-2775
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.1.1
>Reporter: Jinmei Liao
>
> Steps to reproduce:
> 1) start a locator with a SecurityManager and with this property: 
> ssl-enabled-components=jmx
> 2) start a browser and tries to login to pulse.
> Actual result: not able to log in using valid username/password



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


[GitHub] geode pull request #454: GEODE-2775: Corrected setting of Pulse SSL Manager ...

2017-04-13 Thread PurelyApplied
GitHub user PurelyApplied opened a pull request:

https://github.com/apache/geode/pull/454

GEODE-2775: Corrected setting of Pulse SSL Manager flag

Flag now set from System properties instead of pulse.properties when 
running in embedded mode.

Precheckin returned fully green.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/PurelyApplied/geode geode-2775

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/454.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #454


commit 9748668b562963716cd8b6bb5d7aa87c6d40d414
Author: Patrick Rhomberg 
Date:   2017-04-12T18:39:11Z

GEODE-2775: Corrected setting of Pulse SSL Manager flag from System 
properties instead of pulse.properties when running in embedded mode.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Joey McAllister
I've re-opened GEODE-2554 to address the redirects.

On Thu, Apr 13, 2017 at 12:43 PM Swapnil Bawaskar 
wrote:

> It's not just google, we also point users to the docs in forums, on user
> list etc. So, these links should never be broken.
> We put the javadocs, under "latest" for example
> /releases/latest/javadoc/index.html, so the link always stays current. Can
> we do something similar for the user guide as well?
>
>
>
> On Thu, Apr 13, 2017 at 12:28 PM Kirk Lund  wrote:
>
> > The old URLs should probably redirect to the greatest version number
> then,
> > right?
> >
> > Either way, we have broken URLs showing up at the top of our google
> > searches. There must be a way of telling Google to flush these out or
> > otherwise fix them.
> >
> > On Thu, Apr 13, 2017 at 12:05 PM, Michael Stolz 
> wrote:
> >
> > > On further inspection, this is due to the versioning that was added in
> > > /docs/guide.
> > > There is now a /docs/guide/10 and a /docs/guide/11 each of which
> > contains a
> > > "configuring" folder a "tools_modules" folder, etc.
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> > >
> > > On Thu, Apr 13, 2017 at 1:40 PM, Kirk Lund  wrote:
> > >
> > > > If I google for something like "apache geode pulse Log-File-Location"
> > > then
> > > > the top few search results are broken. Is this expected or temporary?
> > > >
> > > > https://geode.apache.org/docs/guide/configuring/running/
> > > > running_the_locator.html
> > > >
> > > > Not Found
> > > > The requested URL
> /docs/guide/configuring/running/running_the_locator.
> > > html
> > > > was not found on this server.
> > > >
> > > > https://geode.apache.org/docs/guide/configuring/running/
> > > > running_the_cacheserver.html
> > > >
> > > > Not Found
> > > > The requested URL
> > > > /docs/guide/configuring/running/running_the_cacheserver.html was not
> > > found
> > > > on this server.
> > > >
> > > > https://geode.apache.org/docs/guide/tools_modules/gfsh/
> > > > configuring_gfsh.html
> > > >
> > > > Not Found
> > > > The requested URL
> /docs/guide/tools_modules/gfsh/configuring_gfsh.html
> > > was
> > > > not found on this server.
> > > >
> > > > 
> > > >
> > >
> >
>


Re: Googling Apache Geode docs results in urls Not Found

2017-04-13 Thread Anthony Baker
I submitted these links to https://www.google.com/webmasters/tools/removals 
.

Anthony

> On Apr 13, 2017, at 10:40 AM, Kirk Lund  wrote:
> 
> If I google for something like "apache geode pulse Log-File-Location" then
> the top few search results are broken. Is this expected or temporary?
> 
> https://geode.apache.org/docs/guide/configuring/running/running_the_locator.html
> 
> Not Found
> The requested URL /docs/guide/configuring/running/running_the_locator.html
> was not found on this server.
> 
> https://geode.apache.org/docs/guide/configuring/running/running_the_cacheserver.html
> 
> Not Found
> The requested URL
> /docs/guide/configuring/running/running_the_cacheserver.html was not found
> on this server.
> 
> https://geode.apache.org/docs/guide/tools_modules/gfsh/configuring_gfsh.html
> 
> Not Found
> The requested URL /docs/guide/tools_modules/gfsh/configuring_gfsh.html was
> not found on this server.
> 
> 



[jira] [Comment Edited] (GEODE-2647) ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails with NullPointerException

2017-04-13 Thread Kirk Lund (JIRA)

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

Kirk Lund edited comment on GEODE-2647 at 4/13/17 8:32 PM:
---

>From Darrel Schneider , Mar 15, to dev:

The problem with this test is that is does register interest. The first
client that calls the put method does 2 puts, then a clear, then 2 puts,
then a clear. All of those ops get sent async to the other client. So when
you call the same put method on the second client it can be receiving the
events from the first client. When you see the "null" right after client 2
did a put it is because you processed one of the clears from client1.

>From looking at this test it is unclear to me why is does puts and clears.
For the health stats it is trying to verify I would not think any of these
ops are needed. Or you could add some type of listener on client2 and wait
for it to see 2 clears before you have it execute the put task.

Hope this helps


was (Author: klund):
>From Darrel Schneider , Mar 15, to dev:

The problem with this test is that is does [KL: not?] register interest. The 
first
client that calls the put method does 2 puts, then a clear, then 2 puts,
then a clear. All of those ops get sent async to the other client. So when
you call the same put method on the second client it can be receiving the
events from the first client. When you see the "null" right after client 2
did a put it is because you processed one of the clears from client1.

>From looking at this test it is unclear to me why is does puts and clears.
For the health stats it is trying to verify I would not think any of these
ops are needed. Or you could add some type of listener on client2 and wait
for it to see 2 clears before you have it execute the put task.

Hope this helps

> ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails 
> with NullPointerException
> 
>
> Key: GEODE-2647
> URL: https://issues.apache.org/jira/browse/GEODE-2647
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.ClientHealthStatsDUnitTest$$Lambda$193/1653332728.run
>  in VM 3 running on Host asf902.gq1.ygridcore.net with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
>   at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)
>   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.apache.geode.management.ManagementTestRule$2.evaluate(ManagementTestRule.java:86)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestCl

[jira] [Updated] (GEODE-2647) ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails with NullPointerException

2017-04-13 Thread Kirk Lund (JIRA)

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

Kirk Lund updated GEODE-2647:
-
Labels: Flaky  (was: )

> ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails 
> with NullPointerException
> 
>
> Key: GEODE-2647
> URL: https://issues.apache.org/jira/browse/GEODE-2647
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: Flaky
>
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.management.ClientHealthStatsDUnitTest$$Lambda$193/1653332728.run
>  in VM 3 running on Host asf902.gq1.ygridcore.net with 4 VMs
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
>   at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
>   at 
> org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)
>   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.apache.geode.management.ManagementTestRule$2.evaluate(ManagementTestRule.java:86)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.grad

Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Kirk Lund


> On April 13, 2017, 7:25 p.m., Kirk Lund wrote:
> > I'm finding lots of instances where "withRegion" was changed to 
> > "createRegion" but it's an API or Util class that isn't related to your 
> > Rule changes. You probably don't want to change all of these instances of 
> > "withRegion" -- rather than keep flagging more of these, I'll send the 
> > review as is.
> 
> Jinmei Liao wrote:
> These were originally "createRegion". They were accidentally changed by 
> Jared's regex in his last commit.

Hmm, it might be cleaner to revert that earlier commit that introduced all of 
these.


- Kirk


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171919
---


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c5f07858e93 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/HttpClientRule.java
>  49351d9bba854eef08c20d47b99eb3ce467cabaa 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseDataExportTest.java
>  10ca43b8fc171f75887519deb72700f464f24149 
>   
> geode-assembly/src/test/java/org/apache/geode/tools/pulse/PulseVerificationTest.java
>  5a300a15b06b948603b5e82acba1190e1905b41a 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> 2ac5120a673ed53f7a8f4b1ed077902566e7865d 
>   geode-core/src/test/java/org/apache/geode/cache/ProxyJUnitTest.java 
> 05228addb74b070a4eac13bd61e84b055916a503 
>   
> geode-core/src/test/java/org/apache/geode/cache/partition/PartitionRegionHelperDUnitTest.java
>  c57ce5beebc7bc4e4d7b826d8795d5a8e367f245 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/BaseLineAndCompareQueryPerfJUnitTest.java
>  de2f8d3e159ed199c1bd4b740ce7dd8ed5b82a5f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  d121fe9993e13e07dcea4817a173b80a8342e169 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/RemoteQueryDUnitTest.java
>  5f48dae54cd14beb2affeae8a8f3387f3e7bfae0 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/IndexWithSngleFrmAndMultCondQryJUnitTest.java
>  d5195a6b2c8f1b62955ddd127e28ee74bc63ab21 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/functional/LimitClauseJUnitTest.java
>  1661cc8d5ba

[jira] [Commented] (GEODE-2734) Investigate/discuss message encoding

2017-04-13 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt commented on GEODE-2734:
-

I don't think this is something that should be discussed, though asking folks 
to pitch in names for consideration is a good idea.  Instead of a discussion we 
need to benchmark proposed solutions and also consider writing one from scratch 
for Geode.

See 
https://cwiki.apache.org/confluence/display/GEODE/Message+Serialization+and+Transmission

> Investigate/discuss message encoding
> 
>
> Key: GEODE-2734
> URL: https://issues.apache.org/jira/browse/GEODE-2734
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Brian Baynes
>
> Out of all the great ways to encode messages (Thrift, Protobuf, etc), which 
> should we use here?  Let's discuss and come to consensus.



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


[jira] [Commented] (GEODE-2746) Investigate and Evaluate Existing RPC frameworks.

2017-04-13 Thread Bruce Schuchardt (JIRA)

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

Bruce Schuchardt commented on GEODE-2746:
-

Brian, would you create individual tickets for the different protocols.  I 
think we're down to gRPC, Thrift and Avro.  Then people can divide them up and 
test.

Folks doing this work, please look at this document for some requirements (& 
feel free, of course to comment on the requirements).

See 
https://cwiki.apache.org/confluence/display/GEODE/Message+Serialization+and+Transmission

> Investigate and Evaluate Existing RPC frameworks.
> -
>
> Key: GEODE-2746
> URL: https://issues.apache.org/jira/browse/GEODE-2746
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Galen O'Sullivan
>
> There are several existing RPC frameworks for which you can define the 
> structure of your protocol and the tool will generate code for talking over 
> the wire, generally down to serialization of objects.
> If one of those RPC frameworks does not fit all our requirements, we'll 
> design our own binary protocol. This protocol would define both what kind of 
> messages can be sent and how they are encoded on the wire. How we encode the 
> objects that we are sending in requests, however, could still be pluggable.
> A few contenders:
> * [BERT|http://bert-rpc.org]
> * [thrift|https://thrift.apache.org/]
> * [gRPC|http://www.grpc.io/]
> * [Avro|https://avro.apache.org/]
> These are two not-entirely-common features we will need to have:
> * support for SSL/TLS, ability to connect to a server with IP & port.
> * support for push messages from the server without polling (this is needed 
> for CQs).
> This is one half of GEODE-2734.



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


Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Kirk Lund

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171938
---




geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
Lines 48 (patched)


It would be better for this to be non-static and set within a @Before 
method -- this is just a standard JUnit best practice for all test state. Also, 
if it's static then it gets set early during class-load time. By the time JUnit 
goes to execute any of the tests, the port may no longer be available:
```java
private int restPort;

@Before
public void before() throws Exception {
  restPort = AvailablePortHelper.getRandomAvailableTCPPort();
}
```



geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
Lines 51 (patched)


This should have a null-check. In theory Repository.get() could return a 
null or throw an Exception. The before() will then throw but after() is still 
called and then after() will throw NPE which will cause the original Exception 
from before() to be suppressed.



geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
Line 108 (original), 94 (patched)


Is this @Ignore represented by any GEODE-nn tickets? We should file one (if 
it doesn't already exist) and add the ticket # here.



geode-core/src/test/java/org/apache/geode/management/internal/security/DataCommandsSecurityTest.java
Line 58 (original), 58 (patched)


I liked your use of RuleChain on the 1st page of reviewed code better than 
using @ClassRule and @Rule in this way. The problem is that it presumably finds 
a randomly available port during class-load and then finally uses it later 
during test runtime. 

Also, in general we should prefer @Rule over @ClassRule -- a clean 
environment for each test is more important than shaving a few seconds off by 
starting one server for all tests.



geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
Line 37 (original), 36 (patched)


Why is not ok to use @ClassRule here but it's ok in the other tests?

I'd much prefer to see a consistent pattern applied.



geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
Lines 110 (patched)


I really like this change! Or as Ken and you said "withAutoStart" would be 
ok too.


- Kirk Lund


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>  

Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Jinmei Liao


> On April 13, 2017, 9:35 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/security/DataCommandsSecurityTest.java
> > Line 58 (original), 58 (patched)
> > 
> >
> > I liked your use of RuleChain on the 1st page of reviewed code better 
> > than using @ClassRule and @Rule in this way. The problem is that it 
> > presumably finds a randomly available port during class-load and then 
> > finally uses it later during test runtime. 
> > 
> > Also, in general we should prefer @Rule over @ClassRule -- a clean 
> > environment for each test is more important than shaving a few seconds off 
> > by starting one server for all tests.

I believe this is a valid use case to test though: starting up one server, 
connect, do some commands, disconnect, and connet with another user and on and 
on. It's not just for the benefit of shaving off a few seconds. People do use 
the system this way.


> On April 13, 2017, 9:35 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
> > Line 37 (original), 36 (patched)
> > 
> >
> > Why is not ok to use @ClassRule here but it's ok in the other tests?
> > 
> > I'd much prefer to see a consistent pattern applied.

We should use consistent pattern whenever possible that's for sure. But each 
test is different. I do not use @ClassRule here, because in the test itself, a 
super user can do a "shutdownMember()" operation that would shut down the 
server we started in the @ClassRule. Using the @Rule here will ensure that in 
starting up each test, we have a valid and healthy server running.


> On April 13, 2017, 9:35 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/test/dunit/rules/MemberStarterRule.java
> > Lines 110 (patched)
> > 
> >
> > I really like this change! Or as Ken and you said "withAutoStart" would 
> > be ok too.

We changed to withAutoStart. I like this too.


- Jinmei


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/#review171938
---


On April 12, 2017, 11:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58388/
> ---
> 
> (Updated April 12, 2017, 11:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Finally the reviewboard is behaving now. This is good for review now. I will 
> close the PR.
> 
> * consolidated the two sets of rules.
> * do not allow member start up at test initialization time.
> * validate properties in @Before
> * use provider in the chained rules to get the appropriate ports in @Before
> 
> Jared and I tried to use ServerLauncher/LocatorLauncher to start the 
> respective member in the rules, but precheckin yields many failures. Looks 
> like it has two problems:
> 1) by passing in the workingDir in the launcher alone does not make all the 
> logs go there. I still have to set the user.dir env variable to make some 
> tests pass.
> 2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
> tests fail due to insufficient cleanup.
> Due to the above two reasons, I reverted back to use the old way to start 
> server/locator. This looks like a lean and mean way to get what we needed.
> 
> We also investigated the use of Builder in the rules. At least for now, it 
> doesn't buy us much since we need to do validation/startup servers in @Before 
> of the rules. And it yeilds some duplication code and make the usage not that 
> intuitive.
> 
> As for using AvailablePort.Keeper, Jared and I found out it doesn't really 
> keep the ports, so revert that back as well.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityIntegrationTest.java
>  cbd83e382116dcfc06b0199b69bf91486be22f06 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityPostProcessorTest.java
>  e93561c0b5fc4fa7f89c03ff4055515d6bbb21be 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
>  14113c06532d42833ee67f4fbf97ba24d535f2d3 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestServersJUnitTest.java
>  2a3a036782fbde22f8969337973ca5794a7172b0 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/SwaggerVerificationTest.java
>  a8ab19c0ac7f5cb94148fff725093c

Re: Review Request 58388: GEODE-2730: refactor rules

2017-04-13 Thread Jinmei Liao

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58388/
---

(Updated April 13, 2017, 10:13 p.m.)


Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

Finally the reviewboard is behaving now. This is good for review now. I will 
close the PR.

* consolidated the two sets of rules.
* do not allow member start up at test initialization time.
* validate properties in @Before
* use provider in the chained rules to get the appropriate ports in @Before

Jared and I tried to use ServerLauncher/LocatorLauncher to start the respective 
member in the rules, but precheckin yields many failures. Looks like it has two 
problems:
1) by passing in the workingDir in the launcher alone does not make all the 
logs go there. I still have to set the user.dir env variable to make some tests 
pass.
2) launcher.stop does not stop the cache/locator/server cleanly. Subsequent 
tests fail due to insufficient cleanup.
Due to the above two reasons, I reverted back to use the old way to start 
server/locator. This looks like a lean and mean way to get what we needed.

We also investigated the use of Builder in the rules. At least for now, it 
doesn't buy us much since we need to do validation/startup servers in @Before 
of the rules. And it yeilds some duplication code and make the usage not that 
intuitive.

As for using AvailablePort.Keeper, Jared and I found out it doesn't really keep 
the ports, so revert that back as well.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/rest/internal/web/RestSecurityWithSSLTest.java
 4d142bd6b7aa91b162a4fdf4e546df2d3285290e 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/EmbeddedPulseRule.java
 e41d0fea9a1a89ec247f3f2750cc944083056a87 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterIntegrationTest.java
 dc24a57dcf3243962c27d349da136f09d49b1250 


Diff: https://reviews.apache.org/r/58388/diff/4/

Changes: https://reviews.apache.org/r/58388/diff/3-4/


Testing
---

precheckin successful.


Thanks,

Jinmei Liao



Review Request 58435: GEODE-2647: remove unnecessary client puts from ClientHealthStatsDUnitTest

2017-04-13 Thread Kirk Lund

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58435/
---

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Bugs: GEODE-2647
https://issues.apache.org/jira/browse/GEODE-2647


Repository: geode


Description
---

This removes the puts from the clients which was unnecessary for the tests. By 
removing the puts, the race condition caused by async puts and clears for the 
subscription enabled test is gone.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/management/ClientHealthStatsDUnitTest.java
 51425713175b3c8fe41f1064ac8a02178fd45e38 


Diff: https://reviews.apache.org/r/58435/diff/1/


Testing
---

ClientHealthStatsDUnitTest
precheckin in progress


Thanks,

Kirk Lund



[jira] [Updated] (GEODE-2779) Inconsistent jars deployed on members belonging to the same group

2017-04-13 Thread Jared Stewart (JIRA)

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

Jared Stewart updated GEODE-2779:
-
Affects Version/s: 1.1.0
   1.1.1

> Inconsistent jars deployed on members belonging to the same group
> -
>
> Key: GEODE-2779
> URL: https://issues.apache.org/jira/browse/GEODE-2779
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.1.0, 1.1.1
>Reporter: Jared Stewart
>
> Members of a cluster (with cluster configuration enabled) can end up with 
> inconsistent deployed jars even when they belong to the same groups. 
> Here are the steps to reproduce:
> ```
> gfsh> start locator --name=loc1
> gfsh> start server --name=server1 --group=group1
> gfsh> start server --name=server2 --group=group2
> gfsh> start server --name=server3 --group=group1,group2
> gfsh> deploy --jar=/myJar.jar --group=group1,group2
> gfsh> undeploy --jar=myJar.jar --group=group1
> gfsh> start server --name=server4 --group=group1,group2
> ```
> Then server 4 will have myJar.jar (brought from 
> cluster_config/group2/myJar.jar on the locator) whereas server 3 will not 
> have myJar.jar (it got deleted from server 3 when we undeployed myJar from 
> group 1).



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


[jira] [Created] (GEODE-2779) Inconsistent jars deployed on members belonging to the same group

2017-04-13 Thread Jared Stewart (JIRA)
Jared Stewart created GEODE-2779:


 Summary: Inconsistent jars deployed on members belonging to the 
same group
 Key: GEODE-2779
 URL: https://issues.apache.org/jira/browse/GEODE-2779
 Project: Geode
  Issue Type: Bug
  Components: configuration
Reporter: Jared Stewart


Members of a cluster (with cluster configuration enabled) can end up with 
inconsistent deployed jars even when they belong to the same groups. 

Here are the steps to reproduce:
```
gfsh> start locator --name=loc1
gfsh> start server --name=server1 --group=group1
gfsh> start server --name=server2 --group=group2
gfsh> start server --name=server3 --group=group1,group2

gfsh> deploy --jar=/myJar.jar --group=group1,group2
gfsh> undeploy --jar=myJar.jar --group=group1

gfsh> start server --name=server4 --group=group1,group2
```
Then server 4 will have myJar.jar (brought from cluster_config/group2/myJar.jar 
on the locator) whereas server 3 will not have myJar.jar (it got deleted from 
server 3 when we undeployed myJar from group 1).





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


[jira] [Updated] (GEODE-2779) Inconsistent jars deployed on members belonging to the same group

2017-04-13 Thread Jared Stewart (JIRA)

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

Jared Stewart updated GEODE-2779:
-
Description: 
Members of a cluster (with cluster configuration enabled) can end up with 
inconsistent deployed jars even when they belong to the same groups. 

Here are the steps to reproduce:
{noformat}
gfsh> start locator --name=loc1
gfsh> start server --name=server1 --group=group1
gfsh> start server --name=server2 --group=group2
gfsh> start server --name=server3 --group=group1,group2

gfsh> deploy --jar=/myJar.jar --group=group1,group2
gfsh> undeploy --jar=myJar.jar --group=group1

gfsh> start server --name=server4 --group=group1,group2
{noformat}
Then server 4 will have myJar.jar (brought from cluster_config/group2/myJar.jar 
on the locator) whereas server 3 will not have myJar.jar (it got deleted from 
server 3 when we undeployed myJar from group 1).



  was:
Members of a cluster (with cluster configuration enabled) can end up with 
inconsistent deployed jars even when they belong to the same groups. 

Here are the steps to reproduce:
```
gfsh> start locator --name=loc1
gfsh> start server --name=server1 --group=group1
gfsh> start server --name=server2 --group=group2
gfsh> start server --name=server3 --group=group1,group2

gfsh> deploy --jar=/myJar.jar --group=group1,group2
gfsh> undeploy --jar=myJar.jar --group=group1

gfsh> start server --name=server4 --group=group1,group2
```
Then server 4 will have myJar.jar (brought from cluster_config/group2/myJar.jar 
on the locator) whereas server 3 will not have myJar.jar (it got deleted from 
server 3 when we undeployed myJar from group 1).




> Inconsistent jars deployed on members belonging to the same group
> -
>
> Key: GEODE-2779
> URL: https://issues.apache.org/jira/browse/GEODE-2779
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Affects Versions: 1.1.0, 1.1.1
>Reporter: Jared Stewart
>
> Members of a cluster (with cluster configuration enabled) can end up with 
> inconsistent deployed jars even when they belong to the same groups. 
> Here are the steps to reproduce:
> {noformat}
> gfsh> start locator --name=loc1
> gfsh> start server --name=server1 --group=group1
> gfsh> start server --name=server2 --group=group2
> gfsh> start server --name=server3 --group=group1,group2
> gfsh> deploy --jar=/myJar.jar --group=group1,group2
> gfsh> undeploy --jar=myJar.jar --group=group1
> gfsh> start server --name=server4 --group=group1,group2
> {noformat}
> Then server 4 will have myJar.jar (brought from 
> cluster_config/group2/myJar.jar on the locator) whereas server 3 will not 
> have myJar.jar (it got deleted from server 3 when we undeployed myJar from 
> group 1).



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


Review Request 58436: GEODE-2762: fix varargs warnings

2017-04-13 Thread Kirk Lund

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58436/
---

Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
Rhomberg.


Bugs: GEODE-2762
https://issues.apache.org/jira/browse/GEODE-2762


Repository: geode


Description
---

* fix varargs compilation warnings
* remove unused import


Diffs
-

  geode-core/src/test/java/org/apache/geode/internal/util/ArrayUtilsTest.java 
70da91b9c6ab17a1fa8b8e4dc23cb2a96a2c4989 


Diff: https://reviews.apache.org/r/58436/diff/1/


Testing
---

* ./gradlew clean build -- varargs compilation warnings are gone
* ArrayUtilsTest -- test passes
* precheckin in progress


Thanks,

Kirk Lund



[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #523 was SUCCESSFUL (with 1843 tests)

2017-04-13 Thread Spring CI

---
Spring Data GemFire > Nightly-ApacheGeode > #523 was successful.
---
Scheduled
1845 tests in total.

https://build.spring.io/browse/SGF-NAG-523/





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 58435: GEODE-2647: remove unnecessary client puts from ClientHealthStatsDUnitTest

2017-04-13 Thread Ken Howe

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58435/#review171956
---


Ship it!




Ship It!

- Ken Howe


On April 13, 2017, 10:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58435/
> ---
> 
> (Updated April 13, 2017, 10:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2647
> https://issues.apache.org/jira/browse/GEODE-2647
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This removes the puts from the clients which was unnecessary for the tests. 
> By removing the puts, the race condition caused by async puts and clears for 
> the subscription enabled test is gone.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/ClientHealthStatsDUnitTest.java
>  51425713175b3c8fe41f1064ac8a02178fd45e38 
> 
> 
> Diff: https://reviews.apache.org/r/58435/diff/1/
> 
> 
> Testing
> ---
> 
> ClientHealthStatsDUnitTest
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



Re: Review Request 58435: GEODE-2647: remove unnecessary client puts from ClientHealthStatsDUnitTest

2017-04-13 Thread Jinmei Liao

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58435/#review171961
---


Ship it!




Ship It!

- Jinmei Liao


On April 13, 2017, 10:15 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58435/
> ---
> 
> (Updated April 13, 2017, 10:15 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2647
> https://issues.apache.org/jira/browse/GEODE-2647
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This removes the puts from the clients which was unnecessary for the tests. 
> By removing the puts, the race condition caused by async puts and clears for 
> the subscription enabled test is gone.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/ClientHealthStatsDUnitTest.java
>  51425713175b3c8fe41f1064ac8a02178fd45e38 
> 
> 
> Diff: https://reviews.apache.org/r/58435/diff/1/
> 
> 
> Testing
> ---
> 
> ClientHealthStatsDUnitTest
> precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



[jira] [Commented] (GEODE-2764) Index entry not entered into cluster config xml if region name contains a function call like entrySet()

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2764:
---

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/449
  
@jhuynh1 
I have the changes you mentioned and also added a dunit test to confirm the 
behaviour


> Index entry not entered into cluster config xml if region name contains a 
> function call like entrySet()
> ---
>
> Key: GEODE-2764
> URL: https://issues.apache.org/jira/browse/GEODE-2764
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> Steps to recreate the issue type the following in a gfsh instance:
> 1. start locator --name=locator
> 2. start server --name=server
> 3. create region --name=regionName --type=REPLICATE_PERSISTENT 
> 4. create index --name=regionIndex --region="regionName.entrySet() r" 
> --expression=r.key
> -- this will result in an error message 
> {noformat}
> Failed to create index "regionIndex" due to following reasons
> null
> {noformat}
> Cause:
> The index is created but while putting the entry into the clusterconfig it 
> tries to put the region name as regionName.entrySet() which does not exist. 
> cache.getRegion(regionName.entrySet()) will result in null and no xml entry 
> is added to the clusterconfig. So when the server is restarted, there is no 
> index entry in the cluster config xml hence the index is not re-created.
> Solution:
> If the region name contains the character '(' and ')' spilt the region name 
> at the index of '.' and check if the region exists. 
> If the check returns successful only then enter the entry into the cluster 
> config.



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


[GitHub] geode issue #449: GEODE-2764: Added checks on the region name

2017-04-13 Thread nabarunnag
Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/449
  
@jhuynh1 
I have the changes you mentioned and also added a dunit test to confirm the 
behaviour


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jared Stewart


> On April 13, 2017, 3:25 p.m., Jinmei Liao wrote:
> > geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java
> > Lines 27 (patched)
> > 
> >
> > by checking in this suite, would it cause the tests to be run twice?

Yes, I'll `@Ignore` this suite but leave it around.  It's nice to be able to 
run all of the tests related to a particular feature set like deploy, but we 
don't want them to run twice by default.


- Jared


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/#review171878
---


On April 12, 2017, 6:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58393/
> ---
> 
> (Updated April 12, 2017, 6:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2686: Remove JarClassLoader
> - Remove JarClassLoader
> - Replace ClassPathLoader's collection of JarClassLoaders with a single 
> URLClassLoader
> - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
> 'myJar.v1.jar'
> 
> GEODE-2705: Jars undeployed from cluster configuration will not be loaded 
> from disk on member restart
> 
> GEODE-2686: Add more logging to JarDeployer
> 
> GEODE-2290: Limit scanning of deployed jars
> - Uses fast-classpath-scanner to scan jars for classes containing Functions 
> without eagerly loading all classes in the jar.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 304a1c4 
>   geode-assembly/src/test/resources/expected_jars.txt b7d1dc2 
>   geode-core/build.gradle 757599a 
>   geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
> 9ab7c30 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java
>  f4f4069 
>   geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
> 9cd0589 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 18d4b42 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  f904af1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  08f916b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
>  d052551 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
>  5f1f161 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
>  8df24db 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
>  3f05082 
>   
> geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
>  c52d575 
>   geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
> 6baddaf 
>   
> geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java
>  adc1d2e 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
> a365899 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
>  71daecc 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
>  0cc003e 
>   
> geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  7b0823b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/UserCommandsDUnitTest.java
>  24f5cdb 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c3d7f5e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  cecc8cf 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  7cc84d6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  696d22c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  652ec60 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
> 

[jira] [Resolved] (GEODE-2584) Client can put a register object on the server

2017-04-13 Thread Brian Baynes (JIRA)

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

Brian Baynes resolved GEODE-2584.
-
Resolution: Done

This was based on initial protocol work, which is changing with progress toward 
new protocol.

> Client can put a register object on the server
> --
>
> Key: GEODE-2584
> URL: https://issues.apache.org/jira/browse/GEODE-2584
> Project: Geode
>  Issue Type: Sub-task
>  Components: messaging
>Reporter: Addison
>
> Client should be able to send a put method, a region, a key, and a registered 
> object to the server so that it can be storied there.



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


Re: Review Request 58436: GEODE-2762: fix varargs warnings

2017-04-13 Thread Jinmei Liao

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58436/#review171964
---


Ship it!




Ship It!

- Jinmei Liao


On April 13, 2017, 10:19 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58436/
> ---
> 
> (Updated April 13, 2017, 10:19 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Patrick 
> Rhomberg.
> 
> 
> Bugs: GEODE-2762
> https://issues.apache.org/jira/browse/GEODE-2762
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * fix varargs compilation warnings
> * remove unused import
> 
> 
> Diffs
> -
> 
>   geode-core/src/test/java/org/apache/geode/internal/util/ArrayUtilsTest.java 
> 70da91b9c6ab17a1fa8b8e4dc23cb2a96a2c4989 
> 
> 
> Diff: https://reviews.apache.org/r/58436/diff/1/
> 
> 
> Testing
> ---
> 
> * ./gradlew clean build -- varargs compilation warnings are gone
> * ArrayUtilsTest -- test passes
> * precheckin in progress
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jared Stewart

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/
---

(Updated April 13, 2017, 11:06 p.m.)


Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-2686: Remove JarClassLoader
- Remove JarClassLoader
- Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
- Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

GEODE-2705: Jars undeployed from cluster configuration will not be loaded from 
disk on member restart

GEODE-2686: Add more logging to JarDeployer

GEODE-2290: Limit scanning of deployed jars
- Uses fast-classpath-scanner to scan jars for classes containing Functions 
without eagerly loading all classes in the jar.


Diffs (updated)
-

  geode-assembly/build.gradle 304a1c4 
  geode-assembly/src/test/resources/expected_jars.txt b7d1dc2 
  geode-core/build.gradle 757599a 
  geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
9ab7c30 
  geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java 
f4f4069 
  geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
9cd0589 
  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 18d4b42 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 f904af1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
08f916b 
  
geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
 d052551 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
 5f1f161 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
 8df24db 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
 3f05082 
  
geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
 c52d575 
  geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
6baddaf 
  geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java 
adc1d2e 
  geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
a365899 
  
geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
 71daecc 
  
geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
 0cc003e 
  geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 7b0823b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/UserCommandsDUnitTest.java
 24f5cdb 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 c3d7f5e 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 cecc8cf 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 7cc84d6 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 696d22c 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 652ec60 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 02bad30 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 7350241 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 5f4cd74 
  gradle/dependency-versions.properties da8bdf2 


Diff: https://reviews.apache.org/r/58393/diff/3/

Changes: https://reviews.apache.org/r/58393/diff/2-3/


Testing
---

- Precheckin passed
- Manually deployed jars and executed functions via gfsh


Thanks,

Jared Stewart



Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jared Stewart


> On April 13, 2017, 7:13 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
> > Lines 62 (patched)
> > 
> >
> > You might want to consider changing this to a loop from zero to 
> > getHost(0).getVMCount(). It might be unlikely right now, but it's possible 
> > someone might write a DUnit test that executes before this test which 
> > expands the VMCount beyond the default 4 -- unless extra VMs won't impact 
> > these tests that extend this class?

I made this more robust and added it to `LocatorServerStarterRule` as optional 
functionality.


> On April 13, 2017, 7:13 p.m., Kirk Lund wrote:
> > geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
> > Line 38 (original), 40 (patched)
> > 
> >
> > Having seen super.setUp() abused in horrible ways, I recommend avoiding 
> > this at all costs. You already have a hint of this abuse in this example -- 
> > this  before bounces 3 VMs and then invokes super.before which bounches 
> > those 3 AGAIN and bounces the 4th one.
> > 
> > Change the super class to have:
> > ```java
> > public void beforeClusterConfigTestBase() throws Exception {
> >   ...
> > }
> > ```
> > 
> > Now subclass can create either before() or 
> > beforeClusterConfigDeployJarDUnitTest(). The superclass @Before method(s) 
> > are always executed before the subclass @Before method(s).

Thanks for pointing this out.


- Jared


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/#review171910
---


On April 13, 2017, 11:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58393/
> ---
> 
> (Updated April 13, 2017, 11:06 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2686: Remove JarClassLoader
> - Remove JarClassLoader
> - Replace ClassPathLoader's collection of JarClassLoaders with a single 
> URLClassLoader
> - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
> 'myJar.v1.jar'
> 
> GEODE-2705: Jars undeployed from cluster configuration will not be loaded 
> from disk on member restart
> 
> GEODE-2686: Add more logging to JarDeployer
> 
> GEODE-2290: Limit scanning of deployed jars
> - Uses fast-classpath-scanner to scan jars for classes containing Functions 
> without eagerly loading all classes in the jar.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 304a1c4 
>   geode-assembly/src/test/resources/expected_jars.txt b7d1dc2 
>   geode-core/build.gradle 757599a 
>   geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
> 9ab7c30 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java
>  f4f4069 
>   geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
> 9cd0589 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 18d4b42 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  f904af1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  08f916b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
>  d052551 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
>  5f1f161 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
>  8df24db 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
>  3f05082 
>   
> geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
>  c52d575 
>   geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
> 6baddaf 
>   
> geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java
>  adc1d2e 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
> a365899 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
>  71daecc 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
>  0cc003e 
>   
> geode-core/src/test/java/org/apa

[GitHub] geode issue #453: GEODE-2777 Update docs to be for Geode version 1.2

2017-04-13 Thread davebarnes97
Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/453
  
+1 (Downloaded, built and reviewed)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2777:
---

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/453
  
+1 (Downloaded, built and reviewed)


> Change version number from 1.1 to 1.2 in docs
> -
>
> Key: GEODE-2777
> URL: https://issues.apache.org/jira/browse/GEODE-2777
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
> `geode-docs` and `geode-book` directories.
> In the `geode-book` directory, make sure to change the hrefs in the subnav 
> from `/11/` to `/12/` and make relevant version changes to the `config.yml` 
> file.



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


[GitHub] geode pull request #450: GEODE-2632: create ClientCachePutBench

2017-04-13 Thread kirklund
Github user kirklund commented on a diff in the pull request:

https://github.com/apache/geode/pull/450#discussion_r111505951
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+
+  this.temporaryFolder.create();
+  this.serverDirectory = this.temporaryFolder.getRoot();
+
+  startServerProcess();
+
+  try {
+startProcessReaders();
+
+ServerLauncher serverLauncher = new Serve

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2632:
---

Github user kirklund commented on a diff in the pull request:

https://github.com/apache/geode/pull/450#discussion_r111505951
  
--- Diff: 
geode-core/src/jmh/java/org/apache/geode/internal/cache/tier/sockets/command/ClientCachePutBench.java
 ---
@@ -0,0 +1,199 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more 
contributor license
+ * agreements. See the NOTICE file distributed with this work for 
additional information regarding
+ * copyright ownership. The ASF licenses this file to You under the Apache 
License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance with the 
License. You may obtain a
+ * copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software 
distributed under the License
+ * is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF 
ANY KIND, either express
+ * or implied. See the License for the specific language governing 
permissions and limitations under
+ * the License.
+ */
+package org.apache.geode.internal.cache.tier.sockets.command;
+
+import static java.lang.System.*;
+import static java.util.concurrent.TimeUnit.*;
+import static org.apache.commons.io.FileUtils.*;
+import static org.apache.commons.lang.StringUtils.*;
+import static org.apache.geode.cache.client.ClientRegionShortcut.*;
+import static org.apache.geode.distributed.AbstractLauncher.Status.*;
+import static org.apache.geode.distributed.ConfigurationProperties.*;
+import static org.apache.geode.distributed.internal.DistributionConfig.*;
+import static org.apache.geode.internal.AvailablePort.*;
+import static org.apache.geode.test.dunit.NetworkUtils.*;
+import static org.assertj.core.api.Assertions.*;
+import static org.awaitility.Awaitility.*;
+
+import org.apache.geode.cache.Region;
+import org.apache.geode.cache.client.ClientCache;
+import org.apache.geode.cache.client.ClientCacheFactory;
+import org.apache.geode.distributed.ServerLauncher;
+import org.apache.geode.internal.process.ProcessStreamReader;
+import org.junit.rules.TemporaryFolder;
+import org.openjdk.jmh.annotations.Benchmark;
+import org.openjdk.jmh.annotations.BenchmarkMode;
+import org.openjdk.jmh.annotations.Fork;
+import org.openjdk.jmh.annotations.Level;
+import org.openjdk.jmh.annotations.Measurement;
+import org.openjdk.jmh.annotations.Mode;
+import org.openjdk.jmh.annotations.OutputTimeUnit;
+import org.openjdk.jmh.annotations.Scope;
+import org.openjdk.jmh.annotations.Setup;
+import org.openjdk.jmh.annotations.State;
+import org.openjdk.jmh.annotations.TearDown;
+import org.openjdk.jmh.annotations.Warmup;
+
+import java.io.File;
+import java.io.IOException;
+import java.net.URL;
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Random;
+import java.util.concurrent.TimeUnit;
+
+/**
+ * Benchmark that measures throughput of client performing puts to a loner 
server.
+ */
+@Measurement(iterations = 3, time = 3, timeUnit = MINUTES)
+@Warmup(iterations = 3, time = 1, timeUnit = MINUTES)
+@Fork(3)
+@BenchmarkMode(Mode.Throughput)
+@OutputTimeUnit(TimeUnit.SECONDS)
+@State(Scope.Thread)
+@SuppressWarnings("unused")
+public class ClientCachePutBench {
+
+  static final long PROCESS_READER_TIMEOUT = 60 * 1000;
+  static final String CLASS_NAME = 
ClientCachePutBench.class.getSimpleName();
+  static final String PACKAGE_NAME =
+  replace(ClientCachePutBench.class.getPackage().getName(), ".", "/");
+  static final String REGION_NAME = CLASS_NAME + "-region";
+  static final String SERVER_XML_NAME = "/" + PACKAGE_NAME + "/" + 
CLASS_NAME + "-server.xml";
+
+  @State(Scope.Benchmark)
+  public static class ClientState {
+
+Random random;
+Region region;
+
+private Process process;
+private volatile ProcessStreamReader processOutReader;
+private volatile ProcessStreamReader processErrReader;
+
+private int serverPort;
+private ServerLauncher launcher;
+private File serverDirectory;
+private ClientCache clientCache;
+
+private TemporaryFolder temporaryFolder = new TemporaryFolder();
+
+@Setup(Level.Trial)
+public void startServer() throws Exception {
+  System.out.println("\n" + "[ClientCachePutBench] startServer");
+
+  this.random = new Random(nanoTime());
+
+ 

[GitHub] geode issue #453: GEODE-2777 Update docs to be for Geode version 1.2

2017-04-13 Thread joeymcallister
Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/453
  
+1. Updated config works correctly. Scanned and spot-checked subnav links, 
and found no issues. New redirect for archived 1.1 version looks correct.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2777) Change version number from 1.1 to 1.2 in docs

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2777:
---

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/453
  
+1. Updated config works correctly. Scanned and spot-checked subnav links, 
and found no issues. New redirect for archived 1.1 version looks correct.


> Change version number from 1.1 to 1.2 in docs
> -
>
> Key: GEODE-2777
> URL: https://issues.apache.org/jira/browse/GEODE-2777
> Project: Geode
>  Issue Type: Task
>  Components: docs
>Reporter: Joey McAllister
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> On the `develop` branch, change any reference to v1.1 to be v1.2 in the 
> `geode-docs` and `geode-book` directories.
> In the `geode-book` directory, make sure to change the hrefs in the subnav 
> from `/11/` to `/12/` and make relevant version changes to the `config.yml` 
> file.



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


Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jared Stewart

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/
---

(Updated April 13, 2017, 11:33 p.m.)


Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

GEODE-2686: Remove JarClassLoader
- Remove JarClassLoader
- Replace ClassPathLoader's collection of JarClassLoaders with a single 
URLClassLoader
- Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
'myJar.v1.jar'

GEODE-2705: Jars undeployed from cluster configuration will not be loaded from 
disk on member restart

GEODE-2686: Add more logging to JarDeployer

GEODE-2290: Limit scanning of deployed jars
- Uses fast-classpath-scanner to scan jars for classes containing Functions 
without eagerly loading all classes in the jar.


Diffs (updated)
-

  geode-assembly/build.gradle 304a1c4 
  geode-assembly/src/test/resources/expected_jars.txt b7d1dc2 
  geode-core/build.gradle 757599a 
  geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
9ab7c30 
  geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java 
f4f4069 
  geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
9cd0589 
  geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 18d4b42 
  
geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
 f904af1 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
08f916b 
  
geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
 d052551 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
 5f1f161 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
 8df24db 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
 3f05082 
  
geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
 c52d575 
  geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
6baddaf 
  geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java 
adc1d2e 
  geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
a365899 
  
geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
 71daecc 
  
geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
 0cc003e 
  geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
 7b0823b 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/UserCommandsDUnitTest.java
 24f5cdb 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
 c3d7f5e 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
 cecc8cf 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
 7cc84d6 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
 696d22c 
  
geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
 652ec60 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 0a4785d 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
 97c636b 
  
geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest_FunctionATemplate
 PRE-CREATION 
  
geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest_FunctionBTemplate
 PRE-CREATION 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/CommandOverHttpDUnitTest.java
 5f4cd74 
  gradle/dependency-versions.properties da8bdf2 


Diff: https://reviews.apache.org/r/58393/diff/4/

Changes: https://reviews.apache.org/r/58393/diff/3-4/


Testing
---

- Precheckin passed
- Manually deployed jars and executed functions via gfsh


Thanks,

Jared Stewart



Re: Review Request 58393: GEODE-2686: Remove JarClassLoader

2017-04-13 Thread Jinmei Liao

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/58393/#review171971
---


Ship it!




Ship It!

- Jinmei Liao


On April 13, 2017, 11:33 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/58393/
> ---
> 
> (Updated April 13, 2017, 11:33 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2686: Remove JarClassLoader
> - Remove JarClassLoader
> - Replace ClassPathLoader's collection of JarClassLoaders with a single 
> URLClassLoader
> - Change naming scheme for deployed jars from 'vf.gf#myJar.jar#1' to 
> 'myJar.v1.jar'
> 
> GEODE-2705: Jars undeployed from cluster configuration will not be loaded 
> from disk on member restart
> 
> GEODE-2686: Add more logging to JarDeployer
> 
> GEODE-2290: Limit scanning of deployed jars
> - Uses fast-classpath-scanner to scan jars for classes containing Functions 
> without eagerly loading all classes in the jar.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 304a1c4 
>   geode-assembly/src/test/resources/expected_jars.txt b7d1dc2 
>   geode-core/build.gradle 757599a 
>   geode-core/src/main/java/org/apache/geode/internal/ClassPathLoader.java 
> 9ab7c30 
>   geode-core/src/main/java/org/apache/geode/internal/DeployedJar.java 
> PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java
>  f4f4069 
>   geode-core/src/main/java/org/apache/geode/internal/JarClassLoader.java 
> 9cd0589 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 18d4b42 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/ClusterConfigurationLoader.java
>  f904af1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  08f916b 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/persistence/BackupManager.java
>  d052551 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DeployFunction.java
>  5f1f161 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ListDeployedFunction.java
>  8df24db 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/UndeployFunction.java
>  3f05082 
>   
> geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderIntegrationTest.java
>  c52d575 
>   geode-core/src/test/java/org/apache/geode/internal/ClassPathLoaderTest.java 
> 6baddaf 
>   
> geode-core/src/test/java/org/apache/geode/internal/DeployedJarJUnitTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarClassLoaderJUnitTest.java
>  adc1d2e 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerDUnitTest.java 
> a365899 
>   
> geode-core/src/test/java/org/apache/geode/internal/JarDeployerIntegrationTest.java
>  71daecc 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/IncrementalBackupDUnitTest.java
>  0cc003e 
>   
> geode-core/src/test/java/org/apache/geode/management/DeployJarTestSuite.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/DeployCommandsDUnitTest.java
>  7b0823b 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/UserCommandsDUnitTest.java
>  24f5cdb 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfig.java
>  c3d7f5e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigBaseTest.java
>  cecc8cf 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDeployJarDUnitTest.java
>  7cc84d6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigImportDUnitTest.java
>  696d22c 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigStartMemberDUnitTest.java
>  652ec60 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  0a4785d 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  97c636b 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest_FunctionATemplate
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/cli/commands/DeployCommandRedeployDUnitTest_FunctionBTemplate
>  PRE-CREATION 
>   
> geode-web/src/test/java/org/apache/geode/management/int

[GitHub] geode pull request #455: GEODE-2770 - Move the shutdown of the rest interfac...

2017-04-13 Thread charliemblack
GitHub user charliemblack opened a pull request:

https://github.com/apache/geode/pull/455

GEODE-2770 - Move the shutdown of the rest interface to the same plac…

Moving the shutdown of the rest interface to the sample pace as other 
client APIs.   This will prevent a rest api client interaction from mutating 
the state of the system after key components are already shutdown.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/charliemblack/geode feature/GEODE-2770

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/455.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #455


commit 83eb7234b30dd4a5363bb8f1cecb674a3029736e
Author: Charlie Black 
Date:   2017-04-11T04:58:43Z

GEODE-2770 - Move the shutdown of the rest interface to the same place as 
other client APIs.   This will prevent a some client interaction from mutating 
the state of the system after key components are already shutdown.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Commented] (GEODE-2770) When using the REST API it is possible for the API to be accepting requests after the system has shutdown

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on GEODE-2770:
---

GitHub user charliemblack opened a pull request:

https://github.com/apache/geode/pull/455

GEODE-2770 - Move the shutdown of the rest interface to the same plac…

Moving the shutdown of the rest interface to the sample pace as other 
client APIs.   This will prevent a rest api client interaction from mutating 
the state of the system after key components are already shutdown.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/charliemblack/geode feature/GEODE-2770

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/geode/pull/455.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #455


commit 83eb7234b30dd4a5363bb8f1cecb674a3029736e
Author: Charlie Black 
Date:   2017-04-11T04:58:43Z

GEODE-2770 - Move the shutdown of the rest interface to the same place as 
other client APIs.   This will prevent a some client interaction from mutating 
the state of the system after key components are already shutdown.




> When using the REST API it is possible for the API to be accepting requests 
> after the system has shutdown
> -
>
> Key: GEODE-2770
> URL: https://issues.apache.org/jira/browse/GEODE-2770
> Project: Geode
>  Issue Type: Improvement
>  Components: rest (dev)
>Reporter: Charlie Black
>
> When using the REST API it is possible for the API to be accepting requests 
> after the system has shutdown.   The shutdown sequence for the REST API 
> should be next to the other APIs.



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


[GitHub] geode issue #447: Feature/geode 2217

2017-04-13 Thread dalyssakim
Github user dalyssakim commented on the issue:

https://github.com/apache/geode/pull/447
  
Thank you so much ! I will make sure I follow geode commits next time :) !


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Resolved] (GEODE-2217) Add generic type parameter to FunctionContext interface

2017-04-13 Thread Alyssa Kim (JIRA)

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

Alyssa Kim resolved GEODE-2217.
---
Resolution: Fixed

PR merged and closed.

> Add generic type parameter to FunctionContext interface
> ---
>
> Key: GEODE-2217
> URL: https://issues.apache.org/jira/browse/GEODE-2217
> Project: Geode
>  Issue Type: Bug
>  Components: functions
>Reporter: Jared Stewart
>Assignee: Alyssa Kim
>
> FunctionContext has a method getArguments() that returns Object.  It would be 
> nice to have getArguments return a known type instead.
> ```
> public interface FunctionContext  {
>   public T getArguments();
> }
> ```
> The Function interface would then allow users to bound the expected argument 
> type:
> ```
> public interface Function {
>   public void execute(FunctionContext context);
> }
> ```



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


[jira] [Commented] (GEODE-728) Rename Execution.withArgs to Execution.setArguments

2017-04-13 Thread Alyssa Kim (JIRA)

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

Alyssa Kim commented on GEODE-728:
--

Reference Document
[Function Service Usability 
Improvements|https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvements]

> Rename Execution.withArgs to Execution.setArguments
> ---
>
> Key: GEODE-728
> URL: https://issues.apache.org/jira/browse/GEODE-728
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, functions
>Reporter: Dan Smith
>Assignee: Alyssa Kim
>
> FunctionContext has a getArguments method. withArgs should be renamed to 
> match.
> See this discussion on the mailing list.
> http://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201512.mbox/browser



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


Build failed in Jenkins: Geode-flakyTest #17

2017-04-13 Thread Apache Jenkins Server
See 


Changes:

[eshu] GEODE-2773: Fix assertion error in the test.

[jiliao] GEODE-2730: refactor rules

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on qnode2 (ubuntu) in workspace 

 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 6a88f1bcce2ef09a814a6f7545896cc4f0c26da7 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 6a88f1bcce2ef09a814a6f7545896cc4f0c26da7
 > git branch -a -v --no-abbrev # timeout=10
 > git branch -D develop # timeout=10
 > git checkout -b develop 6a88f1bcce2ef09a814a6f7545896cc4f0c26da7
 > git rev-list c9b036b40d3eed0028629d6e90c833da96063986 # timeout=10
[Geode-flakyTest] $ /bin/bash -xe /tmp/hudson1515113608582492219.sh
+ git clean -fdx
warning: failed to remove 
buildSrc/.gradle/2.14.1/taskArtifacts/fileSnapshotsToTreeSnapshotsIndex.bin
warning: failed to remove 
buildSrc/.gradle/2.14.1/taskArtifacts/cache.properties.lock
warning: failed to remove 
buildSrc/.gradle/2.14.1/taskArtifacts/fileSnapshots.bin
warning: failed to remove 
buildSrc/.gradle/2.14.1/taskArtifacts/taskArtifacts.bin
warning: failed to remove buildSrc/.gradle/2.14.1/taskArtifacts/fileHashes.bin
warning: failed to remove buildSrc/.gradle/2.14.1/taskArtifacts/cache.properties
warning: failed to remove 
buildSrc/.gradle/noVersion/buildSrc/cache.properties.lock
warning: failed to remove buildSrc/.gradle/noVersion/buildSrc/cache.properties
warning: failed to remove buildSrc/.gradle/noVersion/buildSrc/built.bin
warning: failed to remove buildSrc/build/libs/buildSrc.jar
warning: failed to remove buildSrc/build/classes/main/PasswordDialog.class
warning: failed to remove 
buildSrc/build/classes/main/PasswordDialog$_askPassword_closure1$_closure2$_closure3.class
warning: failed to remove 
buildSrc/build/classes/main/PasswordDialog$_askPassword_closure1.class
warning: failed to remove 
buildSrc/build/classes/main/PasswordDialog$_askPassword_closure1$_closure2$_closure3$_closure4.class
warning: failed to remove 
buildSrc/build/classes/main/org/apache/geode/gradle/TestPropertiesWriter.class
warning: failed to remove 
buildSrc/build/classes/main/PasswordDialog$_askPassword_closure1$_closure2.class
warning: failed to remove buildSrc/build/tmp/jar/MANIFEST.MF
warning: failed to remove buildSrc/build/tmp/compileGroovy/groovy-java-stubs
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
were found. Configuration error?