date:20170821

Re: Native commit messages going to dev instead of commit list

2017-08-21 Thread Mark Bretl

Oops...that was my copy-paste error on the request. I have opened a new
ticket to update the commit mail,
https://issues.apache.org/jira/browse/INFRA-14924.

--Mark

On Thu, Aug 17, 2017 at 1:43 PM, Dan Smith  wrote:

> Was: Re: [geode-native] branch develop updated: GEODE-3455: Update Solaris
> build images.
>
> Probably need to file an infra ticket. I'm guessing this was caused by the
> gitbox migration.
>
> On Thu, Aug 17, 2017 at 1:40 PM, Jacob Barrett 
> wrote:
>
> > I wonder if the native repo wasn't reconfigured when the main repo was.
> It
> > is not something I can change even though we are not a mirror site.
> >
> >
> > Mark, do you have karma to change this?
> >
> > -Jake
> >
> >
> > On Thu, Aug 17, 2017 at 11:25 AM Dan Smith  wrote:
> >
> > > I think these messages should be going to commits@geode?
> > >
> > > On Thu, Aug 17, 2017 at 11:15 AM,  wrote:
> > >
> > > > This is an automated email from the ASF dual-hosted git repository.
> > > >
> > > > jbarrett pushed a commit to branch develop
> > > > in repository https://gitbox.apache.org/repos/asf/geode-native.git
> > > >
> > > >
> > > > The following commit(s) were added to refs/heads/develop by this
> push:
> > > >  new 0fba5ce  GEODE-3455: Update Solaris build images.
> > > > 0fba5ce is described below
> > > >
> > > > commit 0fba5cee59d5d53eaab6cc9396eab45df4b8d79c
> > > > Author: Jacob Barrett 
> > > > AuthorDate: Wed Aug 2 12:32:34 2017 -0700
> > > >
> > > > GEODE-3455: Update Solaris build images.
> > > >
> > > >  - Fixes Solaris SPARC image.
> > > >  - Addes developer images.
> > > > ---
> > > >  packer/build-solaris-sparc.json | 10 +
> > > >  packer/build-solaris-x86.json   |  7 +++---
> > > >  packer/dev-solaris-sparc.json   | 38
> > > > +
> > > >  packer/dev-solaris-x86.json | 38
> > > > +
> > > >  packer/solaris/install-cmake.sh |  8 ---
> > > >  packer/solaris/install-solarisstudio.sh |  1 -
> > > >  6 files changed, 91 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/packer/build-solaris-sparc.json
> > > b/packer/build-solaris-sparc.
> > > > json
> > > > index 34aea96..0ce5eec 100644
> > > > --- a/packer/build-solaris-sparc.json
> > > > +++ b/packer/build-solaris-sparc.json
> > > > @@ -1,8 +1,9 @@
> > > >  {
> > > >"variables":{
> > > >  "image_name":"build-solaris-sparc",
> > > > -"openstack_source_image":"7e1e66f1-8256-4e29-a314-
> ee7f54b2f720",
> > > > -"vmware_source_image_name":"X.vmx",
> > > > +"openstack_source_image":"",
> > > > +"openstack_flavor":"Oracle Solaris non-global zone - tiny",
> > > > +"vmware_source_image_name":"",
> > > >  "gemfire_archive":"gemfire.tar.gz",
> > > >  "pkg_oracle_com_certificate":"pkg.oracle.com.certificate.pem",
> > > >  "pkg_oracle_com_key":"pkg.oracle.com.key.pem"
> > > > @@ -18,7 +19,7 @@
> > > >"ssh_username":"root",
> > > >"image_name":"native-{{user `version`}}-{{user `image_name`}}
> > > > {{timestamp}}",
> > > >"source_image":"{{user `openstack_source_image`}}",
> > > > -  "flavor":"Oracle Solaris non-global zone - tiny",
> > > > +  "flavor":"{{user `openstack_flavor`}}",
> > > >"insecure":"true"
> > > >  }
> > > >],
> > > > @@ -38,7 +39,8 @@
> > > >"scripts":[
> > > >  "solaris/install-opencsw.sh",
> > > >  "solaris/install-build-tools.sh",
> > > > -"solaris/install-solarisstudio.sh"
> > > > +"solaris/install-solarisstudio.sh",
> > > > +"solaris/install-cmake.sh"
> > > >]
> > > >  },
> > > >  {
> > > > diff --git a/packer/build-solaris-x86.json
> > > b/packer/build-solaris-x86.json
> > > > index b01519e..6a55c82 100644
> > > > --- a/packer/build-solaris-x86.json
> > > > +++ b/packer/build-solaris-x86.json
> > > > @@ -1,8 +1,9 @@
> > > >  {
> > > >"variables":{
> > > >  "image_name":"build-solaris-x86",
> > > > -"openstack_source_image":"c0df7ff9-fc8f-4220-ac1f-
> fd24924dfe7a",
> > > > -"vmware_source_image_name":"X.vmx",
> > > > +"openstack_source_image":"",
> > > > +"openstack_flavor":"Oracle Solaris non-global zone - tiny",
> > > > +"vmware_source_image_name":"",
> > > >  "gemfire_archive":"gemfire.tar.gz",
> > > >  "pkg_oracle_com_certificate":"pkg.oracle.com.certificate.pem",
> > > >  "pkg_oracle_com_key":"pkg.oracle.com.key.pem"
> > > > @@ -18,7 +19,7 @@
> > > >"ssh_username":"root",
> > > >"image_name":"native-{{user `version`}}-{{user `image_name`}}
> > > > {{timestamp}}",
> > > >"source_image":"{{user `openstack_source_image`}}",
> > > > -  "flavor":"Oracle Solaris non-global zone - tiny",
> > > > +  "flavor":"{{user `openstack_flavor`}}",
> > > >"insecure":"true"
> > > >  }
> > > >],
> > > >

[GitHub] geode pull request #716: GEODE-3406: Locator accepts Protobuf requests

2017-08-21 Thread galen-pivotal

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/716#discussion_r134270934
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
 ---
@@ -297,6 +297,8 @@ public Object call() throws IOException {
 // able to do so successfully anyway
 p.setProperty(DISABLE_AUTO_RECONNECT, "true");
 
+System.setProperty("geode.feature-protobuf-protocol", "true");
--- End diff --

Do we want to do this for all DUnit tests? On the one hand, it might help 
shake some bugs out; on the other, we're setting a system property for all 
tests.


---
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.
---

[GitHub] geode pull request #716: GEODE-3406: Locator accepts Protobuf requests

2017-08-21 Thread galen-pivotal

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/716#discussion_r134022599
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/ClientProtoclMessageHandlerLoader.java
 ---
@@ -0,0 +1,64 @@
+/*
+ * 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;
+
+import java.io.IOException;
+import java.net.Socket;
+import java.util.Iterator;
+import java.util.ServiceLoader;
+
+import org.apache.geode.internal.cache.InternalCache;
+import org.apache.geode.internal.cache.tier.Acceptor;
+import org.apache.geode.internal.cache.tier.CachedRegionHelper;
+import org.apache.geode.internal.security.SecurityService;
+
+/**
+ * Creates instances of ServerConnection based on the connection mode 
provided.
+ */
+public class ClientProtoclMessageHandlerLoader {
--- End diff --

Is this a duplicate that will be deleted?


---
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.
---

[GitHub] geode pull request #716: GEODE-3406: Locator accepts Protobuf requests

2017-08-21 Thread galen-pivotal

Github user galen-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/716#discussion_r134024644
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/TcpServerFactory.java
 ---
@@ -0,0 +1,39 @@
+package org.apache.geode.internal.cache.tier.sockets;
+
+import java.net.InetAddress;
+import java.util.Properties;
+
+import org.apache.geode.distributed.internal.DistributionConfigImpl;
+import org.apache.geode.distributed.internal.InternalLocator;
+import org.apache.geode.distributed.internal.PoolStatHelper;
+import org.apache.geode.distributed.internal.tcpserver.TcpHandler;
+import org.apache.geode.distributed.internal.tcpserver.TcpServer;
+
+public class TcpServerFactory {
+  private ClientProtocolMessageHandler protocolHandler;
+
+  public TcpServerFactory() {
+initializeMessageHandler();
+  }
+
+  public TcpServer makeTcpServer(int port, InetAddress bind_address, 
Properties sslConfig,
+  DistributionConfigImpl cfg, TcpHandler handler, PoolStatHelper 
poolHelper,
+  ThreadGroup threadGroup, String threadName, InternalLocator 
internalLocator) {
+
+return new TcpServer(port, bind_address, sslConfig, cfg, handler, 
poolHelper, threadGroup,
+threadName, internalLocator, protocolHandler);
+  }
+
+  public synchronized ClientProtocolMessageHandler 
initializeMessageHandler() {
+if (!Boolean.getBoolean("geode.feature-protobuf-protocol")) {
+  return null;
--- End diff --

If we don't throw here, it will result in an NPE down the line when we try 
to receive a message from the null handler. I think it's better to throw here 
than return null -- see the similar `IOException` thrown by 
`ServerConnectionFactory`.


---
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.
---

[GitHub] geode pull request #730: GEODE-3472: Remove a great deal of commented-out co...

2017-08-21 Thread PurelyApplied

GitHub user PurelyApplied opened a pull request:

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

GEODE-3472: Remove a great deal of commented-out code.

* Correct imports in touched files
* Correct several misspellings
* Removed redundant modifier and specifiers
* Corrected modifier orderings to adhere to style standard
* Removed several //TODO comments
* Removed "throws CheckedException" from methods that no longer throw the 
checked exception.
* Minor refactorings: iterator loops to for-each, simplified conditionals, 
etc.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [n/a] Have you written or updated unit tests to verify your changes? 
[n/a: Non-functional changes.]

- [n/a] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

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

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

https://github.com/apache/geode/pull/730.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 #730


commit 9fb4414b363e9bbc584b67456158ad3f880e269b
Author: Patrick Rhomberg 
Date:   2017-08-18T20:59:44Z

GEODE-3472: Remove a great deal of commented-out code.

* Correct imports in touched files
* Correct several misspellings
* Removed redundant modifier and specifiers
* Corrected modifier orderings to adhere to style standard
* Removed several //TODO comments
* Removed "throws CheckedException" from methods that no longer throw the 
checked exception.
* Minor refactorings: iterator loops to for-each, simplified conditionals, 
etc.




---
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.
---

[geode-native] branch develop updated: GEODE-3497: Fix failing test on Solaris SPARC

2017-08-21 Thread jbarrett

This is an automated email from the ASF dual-hosted git repository.

jbarrett pushed a commit to branch develop
in repository https://gitbox.apache.org/repos/asf/geode-native.git


The following commit(s) were added to refs/heads/develop by this push:
 new cc6dafe  GEODE-3497: Fix failing test on Solaris SPARC
cc6dafe is described below

commit cc6dafee2cd82fa770686fa9b9d87ba4eeb3
Author: David Kimura 
AuthorDate: Mon Aug 21 13:05:49 2017 -0700

GEODE-3497: Fix failing test on Solaris SPARC
---
 cppcache/test/ClientProxyMembershipIDFactoryTest.cpp | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/cppcache/test/ClientProxyMembershipIDFactoryTest.cpp 
b/cppcache/test/ClientProxyMembershipIDFactoryTest.cpp
index b9fec88..d593812 100644
--- a/cppcache/test/ClientProxyMembershipIDFactoryTest.cpp
+++ b/cppcache/test/ClientProxyMembershipIDFactoryTest.cpp
@@ -26,17 +26,18 @@ using namespace apache::geode::client;
 TEST(ClientProxyMembershipIDFactoryTest, testCreate) {
   ClientProxyMembershipIDFactory factory("myDs");
 
-  auto id = factory.create("myHost", 1, 2, "myClientID", 3);
+  auto hostAddr = htonl(1);
+  auto id = factory.create("myHost", hostAddr, 2, "myClientID", 3);
   ASSERT_NE(nullptr, id);
 
   EXPECT_EQ("myDs", id->getDSName());
-  EXPECT_EQ(1, static_cast(*id->getHostAddr()));
+  EXPECT_EQ(hostAddr, *reinterpret_cast(id->getHostAddr()));
   EXPECT_EQ(4, id->getHostAddrLen());
   EXPECT_EQ(2, id->getHostPort());
 
   auto uniqueTag = id->getUniqueTag();
   ASSERT_NE("", uniqueTag);
-  EXPECT_EQ(std::string(":1:0:0:0:2:myDs:").append(uniqueTag),
+  EXPECT_EQ(std::string(":0:0:0:1:2:myDs:").append(uniqueTag),
 id->getHashKey());
   EXPECT_TRUE(std::regex_search(
   id->getDSMemberIdForThinClientUse(),

-- 
To stop receiving notification emails like this one, please contact
['"dev@geode.apache.org" '].

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

2017-08-21 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #654 was successful.
---
Scheduled
2029 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode pull request #729: GEODE-3461: increase test timeouts

2017-08-21 Thread jaredjstewart

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

https://github.com/apache/geode/pull/729#discussion_r134348604
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/process/AbstractProcessStreamReaderIntegrationTest.java
 ---
@@ -149,7 +147,7 @@ protected void 
givenStartedProcessWithStreamListeners(final Class mainClass)
   }
 
   protected ConditionFactory await() {
-return 
Awaitility.await().atMost(WAIT_FOR_READER_IS_RUNNING_TIMEOUT_MILLIS, 
MILLISECONDS);
+return Awaitility.await().atMost(2, MINUTES);
--- End diff --

Did you mean to specify READER_JOIN_TIMEOUT_MILLIS instead of 2?  Otherwise 
it looks like that variable is only read by tests.


---
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: geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Dan Smith

On Mon, Aug 21, 2017 at 3:14 PM, Patrick Rhomberg 
wrote:

> I am also in favor of skipping the download, but now I'm failing my build
>

Yes, but the important part is that it didn't download anything :)

Sorry about that, it looks like I screwed something up. Can you pull and
try again?

-Dan

Re: geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Patrick Rhomberg

I am also in favor of skipping the download, but now I'm failing my build
with

All test reports at /.../build/reports/combined

FAILURE: Build failed with an exception.

* Where:
Build file '/.../geode-old-versions/build.gradle' line: 60

* What went wrong:
Execution failed for task ':geode-old-versions:verifyGeodetest120'.
> java.io.FileNotFoundException:
/.../geode-old-versions/build/apache-geode-1.2.0.tar.gz.sha256 (No such
file or directory)



On Mon, Aug 21, 2017 at 2:28 PM, Kirk Lund  wrote:

> Awesome! Thank you Dan!
>
> On Mon, Aug 21, 2017 at 2:26 PM, Dan Smith  wrote:
>
> > Hi Kirk,
> >
> > I just pushed a fix for this. It should only download geode.1.2.0 the
> first
> > time you build.
> >
> > -Dan
> >
> > On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund  wrote:
> >
> > > Why does "geode-old-versions" download previous versions every time I
> > > rebuild from the command-line? And why is it s slow? Can't we cache
> > > these like other dependencies?
> > >
> > > :geode-old-versions:compileJava UP-TO-DATE
> > > :geode-old-versions:downloadSHAtest120
> > > Download
> > > https://www.apache.org/dist/geode/1.2.0/apache-geode-1.2.
> 0.tar.gz.sha256
> > > :geode-old-versions:downloadZipFiletest120
> > > Download
> > > https://www.apache.org/dyn/closer.cgi?action=download;
> > > filename=geode/1.2.0/apache-geode-1.2.0.tar.gz
> > > > Building 13% > :geode-old-versions:downloadZipFiletest120 > 32.81
> > > MB/87.14 MB downloaded
> > >
> > > A *couple minutes later* and it's still 13% and very slow...
> > >
> > > > Building 13% > :geode-old-versions:downloadZipFiletest120 > 51.41
> > > MB/87.14 MB downloaded
> > >
> >
>

Re: Review Request 61802: GEODE-3445: Add gfsh connect option --skip-ssl-validation

2017-08-21 Thread Jared Stewart


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

(Updated Aug. 21, 2017, 10:09 p.m.)


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


Changes
---

Update help text


Repository: geode


Description
---

GEODE-3445: Add gfsh connect option --skip-ssl-validation


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/management/GfshConnectToLocatorWithSSLAcceptanceTest.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshRule.java
 fa25f14 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshScript.java
 52ef0d3 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
 274f61c 


Diff: https://reviews.apache.org/r/61802/diff/2/

Changes: https://reviews.apache.org/r/61802/diff/1-2/


Testing
---

Precheckin running


Thanks,

Jared Stewart

Build failed in Jenkins: Geode-nightly #930

2017-08-21 Thread Apache Jenkins Server

See 

--
[...truncated 123.55 KB...]
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:spotlessJavaCheck
:geode-core:spotlessCheck
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-junit:processTestResources
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.

:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:integrationTest
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-protobuf:assemble
:geode-protobuf:extractIncludeTestProto
:geode-protobuf:extractTestProto UP-TO-DATE
:geode-protobuf:generateTestProto UP-TO-DATE
:geode-protobuf:compileTestJavaNote: Some input files use unchecked or unsafe 
operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-protobuf:processTestResources
:geode-protobuf:testClasses
:geode-protobuf:checkMissedTests
:geode-protobuf:spotlessJavaCheck
:geode-protobuf:spotlessCheck
:geode-protobuf:test
:geode-protobuf:check
:geode-protobuf:build
:geode-protobuf:distributedTest
:geode-protobuf:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: 

 uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test

Re: Review Request 61757: GEODE-2859: Fix ShowDeadlockDUnitTest

2017-08-21 Thread Kirk Lund


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


Ship it!




Ship It!

- Kirk Lund


On Aug. 18, 2017, 9:40 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61757/
> ---
> 
> (Updated Aug. 18, 2017, 9:40 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2859: Fix ShowDeadlockDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
>  8b5c80e4dd63d894bb305c618b9c12ca1e318b52 
> 
> 
> Diff: https://reviews.apache.org/r/61757/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 61758: GEODE-3471: Identify NPE in MBeanProxyFactory

2017-08-21 Thread Kirk Lund


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


Ship it!




Ship It!

- Kirk Lund


On Aug. 18, 2017, 9:55 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61758/
> ---
> 
> (Updated Aug. 18, 2017, 9:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3471: Identify NPE in MBeanProxyFactory
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
>  0cce0be22323cf47dd6f90691bb068b3aaa77372 
> 
> 
> Diff: https://reviews.apache.org/r/61758/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[GitHub] geode pull request #702: GEODE-3416: Reduce synchronization blockages in Soc...

2017-08-21 Thread bschuchardt

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

https://github.com/apache/geode/pull/702#discussion_r134339691
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,55 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
+   */
+  @Deprecated
+  private void createThreadPool() {
+ExecutorService executorService;
+final ThreadGroup threadGroup =
+LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
+ThreadFactory threadFactory = new ThreadFactory() {
+  public Thread newThread(final Runnable command) {
+Thread thread = new Thread(threadGroup, command);
+thread.setDaemon(true);
+return thread;
+  }
+};
+
+executorService = new ThreadPoolExecutor(asyncClosePoolMaxThreads, 
asyncClosePoolMaxThreads,
+asyncCloseWaitTime, asyncCloseWaitUnits, new 
LinkedBlockingQueue<>(), threadFactory);
   }
 
   /**
* Call this method if you know all the resources in the closer for the 
given address are no
* longer needed. Currently a thread pool is kept for each address and 
if you know that an address
* no longer needs its pool then you should call this method.
*/
-  public void releaseResourcesForAddress(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool != null) {
-pool.shutdown();
-asyncCloseExecutors.remove(address);
-  }
-}
-  }
 
-  private boolean isClosed() {
-synchronized (asyncCloseExecutors) {
-  return this.closed;
+  public void releaseResourcesForAddress(String address) {
+ExecutorService executorService = asyncCloseExecutors.remove(address);
+if (executorService != null) {
+  executorService.shutdown();
--- End diff --

@kohlmu-pivotal I don't believe that I said it was different behavior.  I 
said it needs extensive testing.


---
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 61802: GEODE-3445: Add gfsh connect option --skip-ssl-validation

2017-08-21 Thread Kirk Lund


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


Ship it!




Ship It!

- Kirk Lund


On Aug. 21, 2017, 9:06 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61802/
> ---
> 
> (Updated Aug. 21, 2017, 9:06 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3445: Add gfsh connect option --skip-ssl-validation
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/GfshConnectToLocatorWithSSLAcceptanceTest.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshRule.java
>  fa25f14328d2cc56b2e0b64d834ed88dde082e8f 
>   
> geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshScript.java
>  52ef0d35a176c6522664eb18449d1c4b635f16a6 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
>  274f61c1f304576f8d8db1d5289875ecea706962 
> 
> 
> Diff: https://reviews.apache.org/r/61802/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 61757: GEODE-2859: Fix ShowDeadlockDUnitTest

2017-08-21 Thread Patrick Rhomberg


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


Ship it!




Ship It!

- Patrick Rhomberg


On Aug. 18, 2017, 9:40 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61757/
> ---
> 
> (Updated Aug. 18, 2017, 9:40 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2859: Fix ShowDeadlockDUnitTest
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
>  8b5c80e4dd63d894bb305c618b9c12ca1e318b52 
> 
> 
> Diff: https://reviews.apache.org/r/61757/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 61758: GEODE-3471: Identify NPE in MBeanProxyFactory

2017-08-21 Thread Patrick Rhomberg


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


Ship it!




Ship It!

- Patrick Rhomberg


On Aug. 18, 2017, 9:55 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61758/
> ---
> 
> (Updated Aug. 18, 2017, 9:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3471: Identify NPE in MBeanProxyFactory
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
>  0cce0be22323cf47dd6f90691bb068b3aaa77372 
> 
> 
> Diff: https://reviews.apache.org/r/61758/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[GitHub] geode issue #724: GEODE-3469: prevent zero pid from AvailablePid for tests

2017-08-21 Thread kirklund

Github user kirklund commented on the issue:

https://github.com/apache/geode/pull/724
  
Already merged in.


---
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: geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Kirk Lund

Awesome! Thank you Dan!

On Mon, Aug 21, 2017 at 2:26 PM, Dan Smith  wrote:

> Hi Kirk,
>
> I just pushed a fix for this. It should only download geode.1.2.0 the first
> time you build.
>
> -Dan
>
> On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund  wrote:
>
> > Why does "geode-old-versions" download previous versions every time I
> > rebuild from the command-line? And why is it s slow? Can't we cache
> > these like other dependencies?
> >
> > :geode-old-versions:compileJava UP-TO-DATE
> > :geode-old-versions:downloadSHAtest120
> > Download
> > https://www.apache.org/dist/geode/1.2.0/apache-geode-1.2.0.tar.gz.sha256
> > :geode-old-versions:downloadZipFiletest120
> > Download
> > https://www.apache.org/dyn/closer.cgi?action=download;
> > filename=geode/1.2.0/apache-geode-1.2.0.tar.gz
> > > Building 13% > :geode-old-versions:downloadZipFiletest120 > 32.81
> > MB/87.14 MB downloaded
> >
> > A *couple minutes later* and it's still 13% and very slow...
> >
> > > Building 13% > :geode-old-versions:downloadZipFiletest120 > 51.41
> > MB/87.14 MB downloaded
> >
>

Re: geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Dan Smith

Hi Kirk,

I just pushed a fix for this. It should only download geode.1.2.0 the first
time you build.

-Dan

On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund  wrote:

> Why does "geode-old-versions" download previous versions every time I
> rebuild from the command-line? And why is it s slow? Can't we cache
> these like other dependencies?
>
> :geode-old-versions:compileJava UP-TO-DATE
> :geode-old-versions:downloadSHAtest120
> Download
> https://www.apache.org/dist/geode/1.2.0/apache-geode-1.2.0.tar.gz.sha256
> :geode-old-versions:downloadZipFiletest120
> Download
> https://www.apache.org/dyn/closer.cgi?action=download;
> filename=geode/1.2.0/apache-geode-1.2.0.tar.gz
> > Building 13% > :geode-old-versions:downloadZipFiletest120 > 32.81
> MB/87.14 MB downloaded
>
> A *couple minutes later* and it's still 13% and very slow...
>
> > Building 13% > :geode-old-versions:downloadZipFiletest120 > 51.41
> MB/87.14 MB downloaded
>

[GitHub] geode pull request #728: Don't download geode 1.2 every time a build runs

2017-08-21 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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: geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Kirk Lund

So I gave up after 10 minutes, killed my build and restarted it. Now it
finished much faster. I had the same thing happen earlier today around
9:15am.

"geode-old-versions" is definitely a problem now... either we're not
fetching the previous versions correctly or the infra it's on is broken or
we should be caching this like other dependencies. I don't see why I need
to re-download Geode 1.2.0 EVERY single time I do a clean build.

On Mon, Aug 21, 2017 at 2:19 PM, Kirk Lund  wrote:

> Why does "geode-old-versions" download previous versions every time I
> rebuild from the command-line? And why is it s slow? Can't we cache
> these like other dependencies?
>
> :geode-old-versions:compileJava UP-TO-DATE
> :geode-old-versions:downloadSHAtest120
> Download https://www.apache.org/dist/geode/1.2.0/apache-geode-1.2.
> 0.tar.gz.sha256
> :geode-old-versions:downloadZipFiletest120
> Download https://www.apache.org/dyn/closer.cgi?action=download;
> filename=geode/1.2.0/apache-geode-1.2.0.tar.gz
> > Building 13% > :geode-old-versions:downloadZipFiletest120 > 32.81
> MB/87.14 MB downloaded
>
> A *couple minutes later* and it's still 13% and very slow...
>
> > Building 13% > :geode-old-versions:downloadZipFiletest120 > 51.41
> MB/87.14 MB downloaded
>
>

[GitHub] geode pull request #725: GEODE-3470: Increased serial gateway sender token t...

2017-08-21 Thread boglesby

Github user boglesby closed the pull request at:

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


---
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.
---

geode-old-versions dependencies is slooooowwww

2017-08-21 Thread Kirk Lund

Why does "geode-old-versions" download previous versions every time I
rebuild from the command-line? And why is it s slow? Can't we cache
these like other dependencies?

:geode-old-versions:compileJava UP-TO-DATE
:geode-old-versions:downloadSHAtest120
Download
https://www.apache.org/dist/geode/1.2.0/apache-geode-1.2.0.tar.gz.sha256
:geode-old-versions:downloadZipFiletest120
Download
https://www.apache.org/dyn/closer.cgi?action=download=geode/1.2.0/apache-geode-1.2.0.tar.gz
> Building 13% > :geode-old-versions:downloadZipFiletest120 > 32.81
MB/87.14 MB downloaded

A *couple minutes later* and it's still 13% and very slow...

> Building 13% > :geode-old-versions:downloadZipFiletest120 > 51.41
MB/87.14 MB downloaded

Review Request 61802: GEODE-3445: Add gfsh connect option --skip-ssl-validation

2017-08-21 Thread Jared Stewart


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

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


Repository: geode


Description
---

GEODE-3445: Add gfsh connect option --skip-ssl-validation


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/GfshConnectToLocatorWithSSLAcceptanceTest.java
 PRE-CREATION 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshRule.java
 fa25f14328d2cc56b2e0b64d834ed88dde082e8f 
  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/gfsh/GfshScript.java
 52ef0d35a176c6522664eb18449d1c4b635f16a6 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConnectCommand.java
 274f61c1f304576f8d8db1d5289875ecea706962 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

[GitHub] geode pull request #702: GEODE-3416: Reduce synchronization blockages in Soc...

2017-08-21 Thread kohlmu-pivotal

Github user kohlmu-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/702#discussion_r134328545
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/net/SocketCloser.java ---
@@ -96,46 +99,55 @@ public int getMaxThreads() {
 return this.asyncClosePoolMaxThreads;
   }
 
-  private ThreadPoolExecutor getAsyncThreadExecutor(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool == null) {
-final ThreadGroup tg = 
LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
-ThreadFactory tf = new ThreadFactory() {
-  public Thread newThread(final Runnable command) {
-Thread thread = new Thread(tg, command);
-thread.setDaemon(true);
-return thread;
-  }
-};
-BlockingQueue workQueue = new 
LinkedBlockingQueue();
-pool = new ThreadPoolExecutor(this.asyncClosePoolMaxThreads, 
this.asyncClosePoolMaxThreads,
-this.asyncClosePoolKeepAliveSeconds, TimeUnit.SECONDS, 
workQueue, tf);
-pool.allowCoreThreadTimeOut(true);
-asyncCloseExecutors.put(address, pool);
+  private ExecutorService getAsyncThreadExecutor(String address) {
+ExecutorService executorService = asyncCloseExecutors.get(address);
+if (executorService == null) {
+  // To be used for pre-1.8 jdk releases.
+  // createThreadPool();
+
+  executorService = 
Executors.newWorkStealingPool(asyncClosePoolMaxThreads);
+
+  ExecutorService previousThreadPoolExecutor =
+  asyncCloseExecutors.putIfAbsent(address, executorService);
+
+  if (previousThreadPoolExecutor != null) {
+executorService.shutdownNow();
+return previousThreadPoolExecutor;
   }
-  return pool;
 }
+return executorService;
+  }
+
+  /**
+   * @deprecated this method is to be used for pre 1.8 jdk.
+   */
+  @Deprecated
+  private void createThreadPool() {
+ExecutorService executorService;
+final ThreadGroup threadGroup =
+LoggingThreadGroup.createThreadGroup("Socket asyncClose", logger);
+ThreadFactory threadFactory = new ThreadFactory() {
+  public Thread newThread(final Runnable command) {
+Thread thread = new Thread(threadGroup, command);
+thread.setDaemon(true);
+return thread;
+  }
+};
+
+executorService = new ThreadPoolExecutor(asyncClosePoolMaxThreads, 
asyncClosePoolMaxThreads,
+asyncCloseWaitTime, asyncCloseWaitUnits, new 
LinkedBlockingQueue<>(), threadFactory);
   }
 
   /**
* Call this method if you know all the resources in the closer for the 
given address are no
* longer needed. Currently a thread pool is kept for each address and 
if you know that an address
* no longer needs its pool then you should call this method.
*/
-  public void releaseResourcesForAddress(String address) {
-synchronized (asyncCloseExecutors) {
-  ThreadPoolExecutor pool = asyncCloseExecutors.get(address);
-  if (pool != null) {
-pool.shutdown();
-asyncCloseExecutors.remove(address);
-  }
-}
-  }
 
-  private boolean isClosed() {
-synchronized (asyncCloseExecutors) {
-  return this.closed;
+  public void releaseResourcesForAddress(String address) {
+ExecutorService executorService = asyncCloseExecutors.remove(address);
+if (executorService != null) {
+  executorService.shutdown();
--- End diff --

@bschuchardt in behavior this code is no different than what the original 
implementation was. The only difference is that the synchronization block's 
scope has been reduced. In addition to that, the thread pool has been replaced 
with newWorkStealingPool. This pool is a little more optimal than the original 
implementation and can reduce the initial startup requirements of a 
ThreadPoolExecutor.


---
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: Revert gradle upgrade

2017-08-21 Thread Mark Bretl

I have checked in the update to move the Gradle Wrapper to 3.5.1, with the
fix for Eclipse IDE, into the develop branch.

Hopefully this time we won't need to revert it.

--Mark

On Tue, Jul 25, 2017 at 2:50 PM, Mark Bretl  wrote:

> Now that we have 1.2.0 out the door, would I be able to get someone to
> verify my fixes from those who were having trouble with Gradle 3.4.1 in
> their IDE?
>
> Thanks,
>
> --Mark
>
> On Wed, Jun 14, 2017 at 5:08 PM, Mark Bretl  wrote:
>
>> I think I figured it out.
>>
>> Here is what I did:
>> Fix was to declare the version of Antlr in the dependencies{} because if
>> no version is set, the ANTLR plugin would default to 2.7.7. This was
>> causing issues since the ANTLR plugin was trying to 'change' the version
>> after dependency resolution for its configuration.
>>
>> I successfully tested imported into Eclipse, so I have checked in the
>> changes on the feature/gradle-3.4.1 branch. Would others take some time to
>> see if it works for them now?
>>
>> --Mark
>>
>> On Tue, May 9, 2017 at 10:51 AM, Udo Kohlmeyer 
>> wrote:
>>
>>> I think we have to check the ANTLR plugin to understand it's
>>> requirements..
>>>
>>> maybe there is a newer plugin version for ANTLR
>>>
>>>
>>> On 5/9/17 10:00, Kirk Lund wrote:
>>>
 I've reverted the upgrade to gradle 3.4.1. I also went ahead and
 created a
 branch that repeats the upgrade:

 feature/gradle-3.4.1

 Feel free to experiment with that branch.

 On Tue, May 9, 2017 at 9:53 AM, Kirk Lund  wrote:

 I'll go ahead and revert the upgrade. Hopefully we can eventually find
> the
> cause so we can repeat the upgrade.
>
> On Mon, May 8, 2017 at 4:19 PM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> wrote:
>
> The "eclipse" target fails, too.
>>
>> Le 5/8/2017 à 3:32 PM, Kirk Lund a écrit :
>>
>> I want to revert the gradle upgrade because it breaks IntelliJ and the
>>> idea
>>> gradle task. Please let me know if you have a problem with this.
>>>
>>> PS: Please be prepared to help me if you vote against me reverting
>>> the
>>> upgrade ;) I really want to be able to work again. Thanks!
>>>
>>>
>>>
>>>
>>
>

[GitHub] geode pull request #728: Don't download geode 1.2 every time a build runs

2017-08-21 Thread upthewaterspout

GitHub user upthewaterspout opened a pull request:

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

Don't download geode 1.2 every time a build runs

Setting the overwrite flag on the download tasks to false so that we
don't download the old version of geode for every build.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [ ] Is your initial contribution a single, squashed commit?

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.

@boglesby @metatype 


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

$ git pull https://github.com/upthewaterspout/incubator-geode 
feature/old_version_download

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

https://github.com/apache/geode/pull/728.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 #728


commit 4574428a1e0196a7477c6cf2b308131acaf91a48
Author: Dan Smith 
Date:   2017-08-21T20:30:22Z

Don't download geode 1.2 every time a build runs

Setting the overwrite flag on the download tasks to false so that we
don't download the old version of geode for every build.




---
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 61758: GEODE-3471: Identify NPE in MBeanProxyFactory

2017-08-21 Thread Jared Stewart



> On Aug. 21, 2017, 5:55 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
> > Lines 83-84 (original), 81-85 (patched)
> > 
> >
> > I might be missing context, but this just a spike to see which of these 
> > methods is returning `null`, yeah?
> > 
> > Is receiving `null` in this context indicative of failure, or should 
> > there be some null checks and handling?  Should we formally check against 
> > null and throw instead of allowing an NPE to bubble up?  Would that be a 
> > more meaningful error than an NPE?

This change is just to help see what's null.  Once we know, we'll be able to 
decide how to properly deal with a null value.


- Jared


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


On Aug. 18, 2017, 9:55 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61758/
> ---
> 
> (Updated Aug. 18, 2017, 9:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3471: Identify NPE in MBeanProxyFactory
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
>  0cce0be22323cf47dd6f90691bb068b3aaa77372 
> 
> 
> Diff: https://reviews.apache.org/r/61758/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Re: Review Request 61758: GEODE-3471: Identify NPE in MBeanProxyFactory

2017-08-21 Thread Patrick Rhomberg


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




geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
Lines 83-84 (original), 81-85 (patched)


I might be missing context, but this just a spike to see which of these 
methods is returning `null`, yeah?

Is receiving `null` in this context indicative of failure, or should there 
be some null checks and handling?  Should we formally check against null and 
throw instead of allowing an NPE to bubble up?  Would that be a more meaningful 
error than an NPE?


- Patrick Rhomberg


On Aug. 18, 2017, 9:55 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/61758/
> ---
> 
> (Updated Aug. 18, 2017, 9:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3471: Identify NPE in MBeanProxyFactory
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/MBeanProxyFactory.java
>  0cce0be22323cf47dd6f90691bb068b3aaa77372 
> 
> 
> Diff: https://reviews.apache.org/r/61758/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[GitHub] geode pull request #727: GEODE-3430: fix varargs usage

2017-08-21 Thread kirklund

GitHub user kirklund opened a pull request:

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

GEODE-3430: fix varargs usage

Also, general cleanup of ConnectCommandTest.


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

$ git pull https://github.com/kirklund/geode GEODE-3430-ConnectCommandTest

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

https://github.com/apache/geode/pull/727.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 #727


commit cbbb597cfc5e3dd8610fbb29d7df3875c02b49e5
Author: Kirk Lund 
Date:   2017-08-21T17:12:08Z

GEODE-3430: fix varargs usage

Also, general cleanup of ConnectCommandTest.




---
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.
---

[GitHub] geode pull request #726: GEODE-3474: protobuf auth with ExampleSecurityManag...

2017-08-21 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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: [Discuss] Compatibility with Apache Xerces

2017-08-21 Thread Jared Stewart

It sounds like these changes ought to be ok.  If there is no objection, I will 
go ahead and pull them in this afternoon.

Thanks,
Jared 

> On Aug 21, 2017, at 9:09 AM, Jacob Barrett  wrote:
> 
> Looking into the legacy repo I can see that the fix for the StringBuffer
> issue was not brought into Geode. The fix was to specifically request the
> Oracle/Sun implementation. Since that implementation might not be available
> in the IBM JDK its probably not a great fix.
> 
> 
> On Fri, Aug 18, 2017 at 9:28 PM Darren Foong  wrote:
> 
>>> You're right. This did come up with the IBM JDK and we fixed it. Not
>> sure why then it's coming up again.
>> 
>> Could it be this? https://issues.apache.org/jira/browse/GEODE-135
>> Seems like a different issue with the IBM JDK though.
>> 
>> I've just verified that the whitespace problem is still an issue with
>> the IBM JDK (because it uses Apache Xerces), and this pull request
>> fixes it.
>> 
>> Not sure why the reporter for GEODE-135 didn't face a similar problem back
>> then.
>> 
>> - Darren
>> 
>> On Sat, Aug 19, 2017 at 6:04 AM, Jacob Barrett 
>> wrote:
>>> You're right. This did come up with the IBM JDK and we fixed it. Not
>> sure why then it's coming up again.
>>> 
>>> Sent from my iPhone
>>> 
>>> On Aug 18, 2017, at 2:01 PM, Dan Smith  wrote:
>>> 
> Since the oracle parser is always going to be there I don't see any
>> harm
 in doing that.
 
 That's not true if we're running on non-oracle JDKs, right? I remember a
 while back someone was trying to run geode on IBMs JDK and having
>> issues -
 maybe even this same whitespace problem?
 
 I think it this fixes issues with other parsers it looks good to me, I
 don't have a problem with adding xerces as a test dependency.
 
 -Dan
 
> On Fri, Aug 18, 2017 at 10:48 AM, Jacob Barrett 
>> wrote:
> 
> I could have sworn at one point the the cache xml parser explicitly
> requested the oracle parser. Since the oracle parser is always going
>> to be
> there I don't see any harm in doing that.
> 
> A better fix might be to just normalize the white space when parsing.
> 
> I also recall xerces having a flag for controlling the white space
> treatment.
> 
> -Jake
> 
> 
> Sent from my iPhone
> 
>> On Aug 18, 2017, at 10:25 AM, Anilkumar Gingade 
> wrote:
>> 
>> Why worry is claiming to support multiple version; and trying to
>> manage/maintain it...
>> 
>> -Anil.
>> 
>> 
>> On Thu, Aug 17, 2017 at 11:35 PM, Darren Foong >> 
>> wrote:
>> 
>>> Hi all,
>>> 
>>> I'm using Geode in an application that uses the Apache implementation
>>> of Xerces. The Oracle JDK comes with its own implementation of
>> Xerces.
>>> 
>>> I encountered an issue
>>> (https://issues.apache.org/jira/browse/GEODE-3306) whereby cache.xml
>>> parsing fails with Apache Xerces; details are in JIRA.
>>> 
>>> Currently there are two workarounds:
>>> 
>>> 1. Remove the whitespace between elements in cache.xml
>>> 2. Load the JDK Xerces when parsing cache.xml
>>> 
>>> I've submitted a pull request
>>> (https://github.com/apache/geode/pull/668) to make `CacheXmlParser`
>>> compatible with both versions of Xerces.
>>> 
>>> This change would be useful for at least two groups of people:
>>> 
>>> 1. Developers who are using the Apache implementation of Xerces
>>> throughout their application, and only want one implementation of
>>> Xerces
>>> 2. Developers who are using a non-Oracle JDK
>>> 
>>> Does anyone have any objections to having `xercesImpl` as a test
>>> runtime dependency?
>>> 
>>> I'd appreciate any feedback. Thank you!
>>> 
>>> Best regards,
>>> - Darren Foong
>>> 
> 
>>

Re: [Discuss] Compatibility with Apache Xerces

2017-08-21 Thread Jacob Barrett

Looking into the legacy repo I can see that the fix for the StringBuffer
issue was not brought into Geode. The fix was to specifically request the
Oracle/Sun implementation. Since that implementation might not be available
in the IBM JDK its probably not a great fix.


On Fri, Aug 18, 2017 at 9:28 PM Darren Foong  wrote:

> > You're right. This did come up with the IBM JDK and we fixed it. Not
> sure why then it's coming up again.
>
> Could it be this? https://issues.apache.org/jira/browse/GEODE-135
> Seems like a different issue with the IBM JDK though.
>
> I've just verified that the whitespace problem is still an issue with
> the IBM JDK (because it uses Apache Xerces), and this pull request
> fixes it.
>
> Not sure why the reporter for GEODE-135 didn't face a similar problem back
> then.
>
> - Darren
>
> On Sat, Aug 19, 2017 at 6:04 AM, Jacob Barrett 
> wrote:
> > You're right. This did come up with the IBM JDK and we fixed it. Not
> sure why then it's coming up again.
> >
> > Sent from my iPhone
> >
> > On Aug 18, 2017, at 2:01 PM, Dan Smith  wrote:
> >
> >>> Since the oracle parser is always going to be there I don't see any
> harm
> >> in doing that.
> >>
> >> That's not true if we're running on non-oracle JDKs, right? I remember a
> >> while back someone was trying to run geode on IBMs JDK and having
> issues -
> >> maybe even this same whitespace problem?
> >>
> >> I think it this fixes issues with other parsers it looks good to me, I
> >> don't have a problem with adding xerces as a test dependency.
> >>
> >> -Dan
> >>
> >>> On Fri, Aug 18, 2017 at 10:48 AM, Jacob Barrett 
> wrote:
> >>>
> >>> I could have sworn at one point the the cache xml parser explicitly
> >>> requested the oracle parser. Since the oracle parser is always going
> to be
> >>> there I don't see any harm in doing that.
> >>>
> >>> A better fix might be to just normalize the white space when parsing.
> >>>
> >>> I also recall xerces having a flag for controlling the white space
> >>> treatment.
> >>>
> >>> -Jake
> >>>
> >>>
> >>> Sent from my iPhone
> >>>
>  On Aug 18, 2017, at 10:25 AM, Anilkumar Gingade 
> >>> wrote:
> 
>  Why worry is claiming to support multiple version; and trying to
>  manage/maintain it...
> 
>  -Anil.
> 
> 
>  On Thu, Aug 17, 2017 at 11:35 PM, Darren Foong  >
>  wrote:
> 
> > Hi all,
> >
> > I'm using Geode in an application that uses the Apache implementation
> > of Xerces. The Oracle JDK comes with its own implementation of
> Xerces.
> >
> > I encountered an issue
> > (https://issues.apache.org/jira/browse/GEODE-3306) whereby cache.xml
> > parsing fails with Apache Xerces; details are in JIRA.
> >
> > Currently there are two workarounds:
> >
> > 1. Remove the whitespace between elements in cache.xml
> > 2. Load the JDK Xerces when parsing cache.xml
> >
> > I've submitted a pull request
> > (https://github.com/apache/geode/pull/668) to make `CacheXmlParser`
> > compatible with both versions of Xerces.
> >
> > This change would be useful for at least two groups of people:
> >
> > 1. Developers who are using the Apache implementation of Xerces
> > throughout their application, and only want one implementation of
> > Xerces
> > 2. Developers who are using a non-Oracle JDK
> >
> > Does anyone have any objections to having `xercesImpl` as a test
> > runtime dependency?
> >
> > I'd appreciate any feedback. Thank you!
> >
> > Best regards,
> > - Darren Foong
> >
> >>>
>

Re: [DISCUSS] authorizing function execution

2017-08-21 Thread Udo Kohlmeyer

When we speak of "users" here, do we mean normal developers or 
"administrational users"?


My concern is that given the current functionality of "deploy jar" it 
would be too easy to deploy a jar, containing a function that has 
"relaxed" user permissions. Which would allow them to execute ANY 
function without being able to stop them.


I believe that the security-level for any function should have a default 
security level and then a power-user or admin needs to override the 
security-level for that function on a per-user, per-role or resource-level.


At least with this approach, the changes to security-level overrides can 
be logged and audited.


--Udo


On 8/21/17 08:56, Anthony Baker wrote:

On Aug 17, 2017, at 1:41 PM, Dan Smith  wrote:

Which means
the develop needs a way override the permission level *before* the function
executes.

I agree.  Providing a callback to allow a user to override the default security 
level seems reasonable.

Anthony

Re: [DISCUSS] authorizing function execution

2017-08-21 Thread Anthony Baker


> On Aug 17, 2017, at 1:41 PM, Dan Smith  wrote:
> 
> Which means
> the develop needs a way override the permission level *before* the function
> executes.

I agree.  Providing a callback to allow a user to override the default security 
level seems reasonable.

Anthony

[GitHub] geode pull request #726: GEODE-3474: protobuf auth with ExampleSecurityManag...

2017-08-21 Thread galen-pivotal

GitHub user galen-pivotal opened a pull request:

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

GEODE-3474: protobuf auth with ExampleSecurityManager

It looks like we were using the wrong constants for the username and 
password strings; ExampleSecurityManager uses some defined constants that look 
more canonical.


### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [x] Have you written or updated unit tests to verify your changes?

- [n/a] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/galen-pivotal/geode feature/GEODE-3474

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

https://github.com/apache/geode/pull/726.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 #726


commit 7db0cad2d5f299c905e0a6f917c2ca4671bd2268
Author: Galen O'Sullivan 
Date:   2017-08-21T15:29:54Z

GEODE-3474: protobuf auth with ExampleSecurityManager




---
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.
---

[Discuss] FunctionStats over the JMX [GEODE-3462]

2017-08-21 Thread Dinesh Akhand

Hi Team,

We are looking for implementing the function stats over JMX.
Currently Function Stats are not part of JMX. We can't see them on JMX server.
Can you please assist what is the correct way to implementing it.

We have many function  which are instanceOf  FunctionAdapter.
We want to monitor their stats on JMX server . can you please assist.

But we having lots of user created function . for monitoring the few critical 
functions, we want then as per configuration based.


GEODE-3462. https://github.com/apache/geode/pull/720

Thanks,
Dinesh Akhand

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer

39 matches

Mail list logo