Build failed in Jenkins: Geode-release #60

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-2420: add file-size-limit param to the ExportLogsController

--
[...truncated 98.57 KB...]
:geode-benchmarks:check
:geode-benchmarks:build
:geode-benchmarks:distributedTest UP-TO-DATE
:geode-benchmarks:integrationTest UP-TO-DATE
:geode-common:assemble
:geode-common:compileTestJava
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:spotlessJavaCheck
:geode-common:spotlessCheck
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
: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

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesRegionsUsingSystemProperty FAILED
java.lang.RuntimeException: Could not start Server
at 
org.apache.geode.redis.GeodeRedisServer.start(GeodeRedisServer.java:387)
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesRegionsUsingSystemProperty(RedisServerTest.java:78)

Caused by:
java.net.BindException: Address already in use

java.lang.NullPointerException
at 
org.apache.geode.redis.GeodeRedisServer.shutdown(GeodeRedisServer.java:629)
at 
org.apache.geode.redis.RedisServerTest.teardown(RedisServerTest.java:46)

org.apache.geode.redis.RedisServerTest > initializeRedisCreatesThreeRegions 
FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesThreeRegions(RedisServerTest.java:54)

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesPartitionedRegionByDefault FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesPartitionedRegionByDefault(RedisServerTest.java:64)

3564 tests completed, 3 failed, 163 skipped
:geode-core:integrationTest FAILED
: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:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
: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:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE

[GitHub] geode-native pull request #102: GEODE-2741: Adding a warning for 64bit Windo...

[pivotal-jbarrett]

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

https://github.com/apache/geode-native/pull/102#discussion_r121248442
  
--- Diff: src/CMakeLists.txt ---
@@ -17,6 +17,15 @@ project(nativeclient)
 
 list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/../cmake)
 
+if(CMAKE_GENERATOR MATCHES Win64*)
+  if ((CMAKE_GENERATOR MATCHES "Visual Studio") AND 
(CMAKE_GENERATOR_TOOLSET STREQUAL ""))
--- End diff --

Why not just set the `CMAKE_GENERATOR_TOOLSET`?


---
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 #565: GEODE-3021: Any call after the first to setPdxStrin...

[jhuynh1]

Github user jhuynh1 closed the pull request at:

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


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

Review Request 59961: GEODE-3048: Introduce a rule to identify tests that require GEODE_HOME

[Jared Stewart]

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

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


Repository: geode


Description
---

GEODE-3048: Introduce a rule to identify tests that require GEODE_HOME

- A subsequent commit will add this rule to all of the relevant tests.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/test/dunit/rules/RequiresGeodeHome.java
 PRE-CREATION 


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


Testing
---


Thanks,

Jared Stewart

Re: SecurityService versus Cluster Config

[Swapnil Bawaskar]

I think we should revisit connecting to the distributed system with
properties. In addition to what Kirk mentioned below, I think one of the
big limitation of this is the inability to change properties on a running
cluster. If there is a property that a user needs to change, they will have
to bounce the cluster as opposed to performing a rolling restart of the
cluster with that property changed. I think the quickest way for us to get
there is to make the connection a two step process, connect just to get the
properties from the cluster config avoiding any validation, then reconnect
using the new set of properties.

On Fri, Jun 9, 2017 at 2:54 PM Kirk Lund  wrote:

> The usage of CacheFactory#setSecurityManager (and setPostProcessor) is
> working as expected, both before and after my changes!
>
> The problem is that Cluster Config is requested during Cache initialization
> which means that any gemfire.properties stored in Cluster Config will not
> be used by DistributedSystem -- only the properties that affect the Cache
> (such as cache-xml-file) are used as expected in Cluster Config. This
> problem exists with/without my changes but my changes exposed this fact by
> moving the use of the security-manager property to DistributedSystem. I'm
> working on a short-term fix specific to security-manager. Correcting the
> problem for all gemfire.properties will be a long-term fix.
>
> On Fri, Jun 9, 2017 at 1:48 PM, John Blum  wrote:
>
> > I am not sure I follow everything that is happening here quite yet as I
> > have not had time to go over this in more detail and digest it.
> >
> > But, I certainly hope that the security-manager property in Geode is not
> > impacted by this in anyway since *Spring Data Geode* builds on this and,
> > well, this
> >  > src/main/java/org/apache/geode/cache/CacheFactory.java#L355-L368>
> > [1],
> > as way to configure Geode (Integrated) Security.
> >
> > Thanks,
> > John
> >
> > [1]
> > https://github.com/apache/geode/blob/develop/geode-core/
> > src/main/java/org/apache/geode/cache/CacheFactory.java#L355-L368
> >
> >
> > On Fri, Jun 9, 2017 at 1:11 PM, Kirk Lund  wrote:
> >
> > > Yeah I think we need #2 in the long run. Right now nearly all of the
> > > gemfire.properties are ignored if you use Cluster Config. The few
> > > gemfire.properties that are mutable by RuntimeDistributionConfigImpl
> will
> > > work when used in Cluster Config -- I believe all other
> > gemfire.properties
> > > would be ignored until we complete #2.
> > >
> > > On Fri, Jun 9, 2017 at 1:02 PM, Udo Kohlmeyer 
> > > wrote:
> > >
> > > > +1 for #2. It does seem more correct
> > > >
> > > >
> > > >
> > > > On 6/9/17 12:45, Kirk Lund wrote:
> > > >
> > > >> The new changes for SecurityService don't work with Cluster Config.
> We
> > > >> only
> > > >> had one test that would've failed but it was annotated with @Ignore.
> > > >>
> > > >> The problem is this:
> > > >>
> > > >> The security-manager is a gemfire property and is now used by the
> > > >> InternalDistributedSystem because membership needs SecurityService
> to
> > > >> handle peer-to-peer authentication. So with my changes, the
> > > >> InternalDistributedSystem now creates SecurityService and passes it
> > into
> > > >> the constructor of GemFireCacheImpl.
> > > >>
> > > >> Next, GemFireCacheImpl#initialize requests Cluster Config. If this
> is
> > a
> > > >> new
> > > >> Server with no gemfire properties, it will have already joined the
> > > Cluster
> > > >> (before and after my changes). It then gets Cluster Config that has
> > > >> gemfire.properties including security-manager. But it's too late,
> the
> > > >> immutable SecurityService has already been created by
> > > >> InternalDistributedSystem.
> > > >>
> > > >> In theory, Cluster Config should be requested before the creation of
> > > >> InternalDistributedSystem so that other gemfire.properties in
> Cluster
> > > >> Config can be applied (such as member-timeout). In fact most of the
> > > >> gemfire.properties control aspects of InternalDistributedSystem.
> > > >> Presently,
> > > >> all gemfire.properties that would configure
> InternalDistributedSystem
> > > are
> > > >> ignored because Cluster Config is loaded after
> > InternalDistributedSystem
> > > >> was created and the member has joined the cluster.
> > > >>
> > > >> We would need to make one of these changes:
> > > >>
> > > >> 1) GemFireCacheImpl creates its own SecurityService which is
> different
> > > >> from
> > > >> the one used by membership. Locators are the only members that
> really
> > > need
> > > >> membership to have a fully configured SecurityService (and I think
> we
> > > >> already have a bug in which 2nd Locators need to be manually
> > configured
> > > >> rather than use Cluster Config).
> > > >>
> > > >> 2) Move Cluster Config request from GemFireCacheImpl to
> > > >> 

[GitHub] geode pull request #572: GEODE-3042: Quick doc of new string-based partition...

[asfgit]

Github user asfgit closed the pull request at:

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


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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #580 was successful.
---
Scheduled
1870 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode issue #572: GEODE-3042: Quick doc of new string-based partition resolv...

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode/pull/572
  
Thanks Dave and Eric.  I've created 
https://issues.apache.org/jira/browse/GEODE-3063 to address further 
documentation for this new feature.  I'm going to merge this 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: SecurityService versus Cluster Config

[Kirk Lund]

The usage of CacheFactory#setSecurityManager (and setPostProcessor) is
working as expected, both before and after my changes!

The problem is that Cluster Config is requested during Cache initialization
which means that any gemfire.properties stored in Cluster Config will not
be used by DistributedSystem -- only the properties that affect the Cache
(such as cache-xml-file) are used as expected in Cluster Config. This
problem exists with/without my changes but my changes exposed this fact by
moving the use of the security-manager property to DistributedSystem. I'm
working on a short-term fix specific to security-manager. Correcting the
problem for all gemfire.properties will be a long-term fix.

On Fri, Jun 9, 2017 at 1:48 PM, John Blum  wrote:

> I am not sure I follow everything that is happening here quite yet as I
> have not had time to go over this in more detail and digest it.
>
> But, I certainly hope that the security-manager property in Geode is not
> impacted by this in anyway since *Spring Data Geode* builds on this and,
> well, this
>  src/main/java/org/apache/geode/cache/CacheFactory.java#L355-L368>
> [1],
> as way to configure Geode (Integrated) Security.
>
> Thanks,
> John
>
> [1]
> https://github.com/apache/geode/blob/develop/geode-core/
> src/main/java/org/apache/geode/cache/CacheFactory.java#L355-L368
>
>
> On Fri, Jun 9, 2017 at 1:11 PM, Kirk Lund  wrote:
>
> > Yeah I think we need #2 in the long run. Right now nearly all of the
> > gemfire.properties are ignored if you use Cluster Config. The few
> > gemfire.properties that are mutable by RuntimeDistributionConfigImpl will
> > work when used in Cluster Config -- I believe all other
> gemfire.properties
> > would be ignored until we complete #2.
> >
> > On Fri, Jun 9, 2017 at 1:02 PM, Udo Kohlmeyer 
> > wrote:
> >
> > > +1 for #2. It does seem more correct
> > >
> > >
> > >
> > > On 6/9/17 12:45, Kirk Lund wrote:
> > >
> > >> The new changes for SecurityService don't work with Cluster Config. We
> > >> only
> > >> had one test that would've failed but it was annotated with @Ignore.
> > >>
> > >> The problem is this:
> > >>
> > >> The security-manager is a gemfire property and is now used by the
> > >> InternalDistributedSystem because membership needs SecurityService to
> > >> handle peer-to-peer authentication. So with my changes, the
> > >> InternalDistributedSystem now creates SecurityService and passes it
> into
> > >> the constructor of GemFireCacheImpl.
> > >>
> > >> Next, GemFireCacheImpl#initialize requests Cluster Config. If this is
> a
> > >> new
> > >> Server with no gemfire properties, it will have already joined the
> > Cluster
> > >> (before and after my changes). It then gets Cluster Config that has
> > >> gemfire.properties including security-manager. But it's too late, the
> > >> immutable SecurityService has already been created by
> > >> InternalDistributedSystem.
> > >>
> > >> In theory, Cluster Config should be requested before the creation of
> > >> InternalDistributedSystem so that other gemfire.properties in Cluster
> > >> Config can be applied (such as member-timeout). In fact most of the
> > >> gemfire.properties control aspects of InternalDistributedSystem.
> > >> Presently,
> > >> all gemfire.properties that would configure InternalDistributedSystem
> > are
> > >> ignored because Cluster Config is loaded after
> InternalDistributedSystem
> > >> was created and the member has joined the cluster.
> > >>
> > >> We would need to make one of these changes:
> > >>
> > >> 1) GemFireCacheImpl creates its own SecurityService which is different
> > >> from
> > >> the one used by membership. Locators are the only members that really
> > need
> > >> membership to have a fully configured SecurityService (and I think we
> > >> already have a bug in which 2nd Locators need to be manually
> configured
> > >> rather than use Cluster Config).
> > >>
> > >> 2) Move Cluster Config request from GemFireCacheImpl to
> > >> InternalDistributedSystem. This is actually more correct, since
> Cluster
> > >> Config is potentially going to contain a lot of
> > InternalDistributedSystem
> > >> configuration options that are currently ignored (in both Geode 1.x
> and
> > >> current develop).
> > >>
> > >> Unfortunately #2 is a fairly big refactoring change.
> > >>
> > >> We should probably revert my changes from develop and 1.2 until #1 or
> #2
> > >> can be completed. Or we have to file a bug that says Cluster Config
> and
> > >> Security don't play nice together until we can complete one of these
> > >> options. I think the latter is probably not acceptable.
> > >>
> > >>
> > >
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>

[GitHub] geode pull request #572: GEODE-3042: Quick doc of new string-based partition...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-3042: Quick doc of new string-based partition resolver

@dschneider-pivotal @davebarnes97 @pivotal-eshu @joeymcallister and all of 
the Geode community:  Please review this PR with world-record speed, as it is 
likely the last item holding up making a 1.2 release candidate.


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

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

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

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


commit 853f06fb938dbf9183b65018a27ce77163b05012
Author: Karen Miller 
Date:   2017-06-09T21:37:04Z

GEODE-3042: Quick doc of new string-based partition resolver




---
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-native pull request #102: GEODE-2741: Adding a warning for 64bit Windo...

[mhansonp]

GitHub user mhansonp opened a pull request:

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

GEODE-2741: Adding a warning for 64bit Windows Tools sets

- Need to include -Thost=x64 in the configuration step

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

$ git pull https://github.com/mhansonp/geode-native feature/GEODE-2741

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

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


commit 262de6dce946f449b68f7dcb253b391a62a9920e
Author: Mark Hanson 
Date:   2017-06-09T21:09:59Z

GEODE-2741: Adding a warning for 64bit Windows Tools sets

- Need to include -Thost=x64 in the configuration step




---
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 #562: GEODE-3025: GET operation before Lucene query

[asfgit]

Github user asfgit closed the pull request at:

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


---
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: SecurityService versus Cluster Config

[John Blum]

I am not sure I follow everything that is happening here quite yet as I
have not had time to go over this in more detail and digest it.

But, I certainly hope that the security-manager property in Geode is not
impacted by this in anyway since *Spring Data Geode* builds on this and,
well, this

[1],
as way to configure Geode (Integrated) Security.

Thanks,
John

[1]
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java#L355-L368


On Fri, Jun 9, 2017 at 1:11 PM, Kirk Lund  wrote:

> Yeah I think we need #2 in the long run. Right now nearly all of the
> gemfire.properties are ignored if you use Cluster Config. The few
> gemfire.properties that are mutable by RuntimeDistributionConfigImpl will
> work when used in Cluster Config -- I believe all other gemfire.properties
> would be ignored until we complete #2.
>
> On Fri, Jun 9, 2017 at 1:02 PM, Udo Kohlmeyer 
> wrote:
>
> > +1 for #2. It does seem more correct
> >
> >
> >
> > On 6/9/17 12:45, Kirk Lund wrote:
> >
> >> The new changes for SecurityService don't work with Cluster Config. We
> >> only
> >> had one test that would've failed but it was annotated with @Ignore.
> >>
> >> The problem is this:
> >>
> >> The security-manager is a gemfire property and is now used by the
> >> InternalDistributedSystem because membership needs SecurityService to
> >> handle peer-to-peer authentication. So with my changes, the
> >> InternalDistributedSystem now creates SecurityService and passes it into
> >> the constructor of GemFireCacheImpl.
> >>
> >> Next, GemFireCacheImpl#initialize requests Cluster Config. If this is a
> >> new
> >> Server with no gemfire properties, it will have already joined the
> Cluster
> >> (before and after my changes). It then gets Cluster Config that has
> >> gemfire.properties including security-manager. But it's too late, the
> >> immutable SecurityService has already been created by
> >> InternalDistributedSystem.
> >>
> >> In theory, Cluster Config should be requested before the creation of
> >> InternalDistributedSystem so that other gemfire.properties in Cluster
> >> Config can be applied (such as member-timeout). In fact most of the
> >> gemfire.properties control aspects of InternalDistributedSystem.
> >> Presently,
> >> all gemfire.properties that would configure InternalDistributedSystem
> are
> >> ignored because Cluster Config is loaded after InternalDistributedSystem
> >> was created and the member has joined the cluster.
> >>
> >> We would need to make one of these changes:
> >>
> >> 1) GemFireCacheImpl creates its own SecurityService which is different
> >> from
> >> the one used by membership. Locators are the only members that really
> need
> >> membership to have a fully configured SecurityService (and I think we
> >> already have a bug in which 2nd Locators need to be manually configured
> >> rather than use Cluster Config).
> >>
> >> 2) Move Cluster Config request from GemFireCacheImpl to
> >> InternalDistributedSystem. This is actually more correct, since Cluster
> >> Config is potentially going to contain a lot of
> InternalDistributedSystem
> >> configuration options that are currently ignored (in both Geode 1.x and
> >> current develop).
> >>
> >> Unfortunately #2 is a fairly big refactoring change.
> >>
> >> We should probably revert my changes from develop and 1.2 until #1 or #2
> >> can be completed. Or we have to file a bug that says Cluster Config and
> >> Security don't play nice together until we can complete one of these
> >> options. I think the latter is probably not acceptable.
> >>
> >>
> >
>



-- 
-John
john.blum10101 (skype)

[GitHub] geode issue #562: GEODE-3025: GET operation before Lucene query

[nabarunnag]

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/562
  
@ladyVader @upthewaterspout @boglesby @gesterzhou 
-- Adding more potential reviewers.



---
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: SecurityService versus Cluster Config

[Kirk Lund]

Yeah I think we need #2 in the long run. Right now nearly all of the
gemfire.properties are ignored if you use Cluster Config. The few
gemfire.properties that are mutable by RuntimeDistributionConfigImpl will
work when used in Cluster Config -- I believe all other gemfire.properties
would be ignored until we complete #2.

On Fri, Jun 9, 2017 at 1:02 PM, Udo Kohlmeyer  wrote:

> +1 for #2. It does seem more correct
>
>
>
> On 6/9/17 12:45, Kirk Lund wrote:
>
>> The new changes for SecurityService don't work with Cluster Config. We
>> only
>> had one test that would've failed but it was annotated with @Ignore.
>>
>> The problem is this:
>>
>> The security-manager is a gemfire property and is now used by the
>> InternalDistributedSystem because membership needs SecurityService to
>> handle peer-to-peer authentication. So with my changes, the
>> InternalDistributedSystem now creates SecurityService and passes it into
>> the constructor of GemFireCacheImpl.
>>
>> Next, GemFireCacheImpl#initialize requests Cluster Config. If this is a
>> new
>> Server with no gemfire properties, it will have already joined the Cluster
>> (before and after my changes). It then gets Cluster Config that has
>> gemfire.properties including security-manager. But it's too late, the
>> immutable SecurityService has already been created by
>> InternalDistributedSystem.
>>
>> In theory, Cluster Config should be requested before the creation of
>> InternalDistributedSystem so that other gemfire.properties in Cluster
>> Config can be applied (such as member-timeout). In fact most of the
>> gemfire.properties control aspects of InternalDistributedSystem.
>> Presently,
>> all gemfire.properties that would configure InternalDistributedSystem are
>> ignored because Cluster Config is loaded after InternalDistributedSystem
>> was created and the member has joined the cluster.
>>
>> We would need to make one of these changes:
>>
>> 1) GemFireCacheImpl creates its own SecurityService which is different
>> from
>> the one used by membership. Locators are the only members that really need
>> membership to have a fully configured SecurityService (and I think we
>> already have a bug in which 2nd Locators need to be manually configured
>> rather than use Cluster Config).
>>
>> 2) Move Cluster Config request from GemFireCacheImpl to
>> InternalDistributedSystem. This is actually more correct, since Cluster
>> Config is potentially going to contain a lot of InternalDistributedSystem
>> configuration options that are currently ignored (in both Geode 1.x and
>> current develop).
>>
>> Unfortunately #2 is a fairly big refactoring change.
>>
>> We should probably revert my changes from develop and 1.2 until #1 or #2
>> can be completed. Or we have to file a bug that says Cluster Config and
>> Security don't play nice together until we can complete one of these
>> options. I think the latter is probably not acceptable.
>>
>>
>

Re: SecurityService versus Cluster Config

[Kirk Lund]

I've reverted my change on release/1.2.0.

I'm currently planning to work on #1 on develop in the short term.

On Fri, Jun 9, 2017 at 12:45 PM, Kirk Lund  wrote:

> The new changes for SecurityService don't work with Cluster Config. We
> only had one test that would've failed but it was annotated with @Ignore.
>
> The problem is this:
>
> The security-manager is a gemfire property and is now used by the
> InternalDistributedSystem because membership needs SecurityService to
> handle peer-to-peer authentication. So with my changes, the
> InternalDistributedSystem now creates SecurityService and passes it into
> the constructor of GemFireCacheImpl.
>
> Next, GemFireCacheImpl#initialize requests Cluster Config. If this is a
> new Server with no gemfire properties, it will have already joined the
> Cluster (before and after my changes). It then gets Cluster Config that has
> gemfire.properties including security-manager. But it's too late, the
> immutable SecurityService has already been created by
> InternalDistributedSystem.
>
> In theory, Cluster Config should be requested before the creation of
> InternalDistributedSystem so that other gemfire.properties in Cluster
> Config can be applied (such as member-timeout). In fact most of the
> gemfire.properties control aspects of InternalDistributedSystem. Presently,
> all gemfire.properties that would configure InternalDistributedSystem are
> ignored because Cluster Config is loaded after InternalDistributedSystem
> was created and the member has joined the cluster.
>
> We would need to make one of these changes:
>
> 1) GemFireCacheImpl creates its own SecurityService which is different
> from the one used by membership. Locators are the only members that really
> need membership to have a fully configured SecurityService (and I think we
> already have a bug in which 2nd Locators need to be manually configured
> rather than use Cluster Config).
>
> 2) Move Cluster Config request from GemFireCacheImpl to
> InternalDistributedSystem. This is actually more correct, since Cluster
> Config is potentially going to contain a lot of InternalDistributedSystem
> configuration options that are currently ignored (in both Geode 1.x and
> current develop).
>
> Unfortunately #2 is a fairly big refactoring change.
>
> We should probably revert my changes from develop and 1.2 until #1 or #2
> can be completed. Or we have to file a bug that says Cluster Config and
> Security don't play nice together until we can complete one of these
> options. I think the latter is probably not acceptable.
>
>

Re: SecurityService versus Cluster Config

[Udo Kohlmeyer]

+1 for #2. It does seem more correct


On 6/9/17 12:45, Kirk Lund wrote:

The new changes for SecurityService don't work with Cluster Config. We only
had one test that would've failed but it was annotated with @Ignore.

The problem is this:

The security-manager is a gemfire property and is now used by the
InternalDistributedSystem because membership needs SecurityService to
handle peer-to-peer authentication. So with my changes, the
InternalDistributedSystem now creates SecurityService and passes it into
the constructor of GemFireCacheImpl.

Next, GemFireCacheImpl#initialize requests Cluster Config. If this is a new
Server with no gemfire properties, it will have already joined the Cluster
(before and after my changes). It then gets Cluster Config that has
gemfire.properties including security-manager. But it's too late, the
immutable SecurityService has already been created by
InternalDistributedSystem.

In theory, Cluster Config should be requested before the creation of
InternalDistributedSystem so that other gemfire.properties in Cluster
Config can be applied (such as member-timeout). In fact most of the
gemfire.properties control aspects of InternalDistributedSystem. Presently,
all gemfire.properties that would configure InternalDistributedSystem are
ignored because Cluster Config is loaded after InternalDistributedSystem
was created and the member has joined the cluster.

We would need to make one of these changes:

1) GemFireCacheImpl creates its own SecurityService which is different from
the one used by membership. Locators are the only members that really need
membership to have a fully configured SecurityService (and I think we
already have a bug in which 2nd Locators need to be manually configured
rather than use Cluster Config).

2) Move Cluster Config request from GemFireCacheImpl to
InternalDistributedSystem. This is actually more correct, since Cluster
Config is potentially going to contain a lot of InternalDistributedSystem
configuration options that are currently ignored (in both Geode 1.x and
current develop).

Unfortunately #2 is a fairly big refactoring change.

We should probably revert my changes from develop and 1.2 until #1 or #2
can be completed. Or we have to file a bug that says Cluster Config and
Security don't play nice together until we can complete one of these
options. I think the latter is probably not acceptable.

[GitHub] geode pull request #551: GEODE-2971: consistency in shell exit codes for sta...

[PurelyApplied]

Github user PurelyApplied closed the pull request at:

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


---
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 issue #551: GEODE-2971: consistency in shell exit codes for status com...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/551
  
After significant testing redesign, this PR will be closed.  The ticket 
will be resolved after additional `@Rule` resources are added that more 
accurately represent real `gfsh` usage.


---
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 #557: add GfshParserRule to facilitate command unit test

[kirklund]

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

https://github.com/apache/geode/pull/557#discussion_r121198226
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
 ---
@@ -0,0 +1,51 @@
+/*
+ * 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.management.internal.cli.commands;
+
+import static org.mockito.Matchers.any;
+import static org.mockito.Mockito.doReturn;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.spy;
+import static org.mockito.Mockito.verify;
+
+import org.apache.geode.management.internal.cli.GfshParseResult;
+import org.apache.geode.management.internal.cli.shell.Gfsh;
+import org.apache.geode.test.dunit.rules.GfshParserRule;
+import org.junit.ClassRule;
+import org.junit.Test;
+import org.mockito.ArgumentCaptor;
+import org.springframework.util.ReflectionUtils;
+
+import java.util.Properties;
+
+public class LauncherLifecycleCommandsTest {
--- End diff --

Need a Category on this test.


---
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 #560: Geode 2818: Adding aliases to any command options t...

[kirklund]

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

https://github.com/apache/geode/pull/560#discussion_r121197448
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
 ---
@@ -736,7 +736,7 @@ public Result exportData(
   @CliOption(key = CliStrings.EXPORT_DATA__FILE,
   unspecifiedDefaultValue = CliMetaData.ANNOTATION_NULL_VALUE, 
mandatory = true,
   help = CliStrings.EXPORT_DATA__FILE__HELP) String filePath,
-  @CliOption(key = CliStrings.EXPORT_DATA__MEMBER,
+  @CliOption(key = CliStrings.MEMBER,
--- End diff --

This makes me wonder if we should file a Jira ticket to make sure all Gfsh 
commands with MEMBER option are consistently allowing comma-delimited lists of 
members.


---
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: git commit message guidelines

[Mark Bretl]

Hey Kirk,

Found it on the wiki,
https://cwiki.apache.org/confluence/display/GEODE/Commit+Message+Format

--Mark

On Fri, Jun 9, 2017 at 11:10 AM, Kirk Lund  wrote:

> Do we have our git commit message guidelines saved or posted somewhere? I'm
> looking at a PR with a VERY long 1st line.
>

[GitHub] geode pull request #565: GEODE-3021: Any call after the first to setPdxStrin...

[jhuynh1]

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

https://github.com/apache/geode/pull/565#discussion_r121196596
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/AbstractIndex.java
 ---
@@ -2002,7 +2002,8 @@ void populateListForEquiJoin(List list, Object 
outerEntries, Object innerEntries
*/
   synchronized void setPdxStringFlag(Object key) {
 // For Null and Undefined keys do not set the isIndexedPdxKeysFlagSet 
flag
-if (key == null || key == IndexManager.NULL || key == 
QueryService.UNDEFINED) {
+if (isIndexedPdxKeysFlagSet || key == null || key == IndexManager.NULL
--- End diff --

They are slightly different.  The isIndexedPdxKeys is represents whether 
the index is storing pdx as keys. The isIndexedPdxKeysFlagSet, is a boolean 
that is used as a short circuit to only call the method once.  I guess it was a 
performance "enhancement" to not call the method over and over for every value 
and just call it only for the first call.


---
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 #565: GEODE-3021: Any call after the first to setPdxStrin...

[kirklund]

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

https://github.com/apache/geode/pull/565#discussion_r121195985
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/AbstractIndex.java
 ---
@@ -2002,7 +2002,8 @@ void populateListForEquiJoin(List list, Object 
outerEntries, Object innerEntries
*/
   synchronized void setPdxStringFlag(Object key) {
 // For Null and Undefined keys do not set the isIndexedPdxKeysFlagSet 
flag
-if (key == null || key == IndexManager.NULL || key == 
QueryService.UNDEFINED) {
+if (isIndexedPdxKeysFlagSet || key == null || key == IndexManager.NULL
--- End diff --

Looks like you have two flags for the same thing... isIndexedPdxKeys and 
isIndexedPdxKeysFlagSet?


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

git commit message guidelines

[Kirk Lund]

Do we have our git commit message guidelines saved or posted somewhere? I'm
looking at a PR with a VERY long 1st line.

[GitHub] geode pull request #571: GEODE-2601: Fixing banner being logged twice during...

[kirklund]

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

https://github.com/apache/geode/pull/571#discussion_r121188665
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/internal/logging/LogWriterFactory.java
 ---
@@ -87,19 +87,19 @@ public static InternalLogWriter 
createLogWriterLogger(final boolean isLoner,
 // LOG:CONFIG:
 logger.info(LogMarker.CONFIG, Banner.getString(null));
   }
+  System.setProperty(InternalLocator.INHIBIT_DM_BANNER, "true"); // 
Ensure no more banners will
--- End diff --

I think we need to find a way to do this without setting INHIBIT_DM_BANNER. 
If the user closes the Cache and reopens it then this system property will 
still be true.


---
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 #571: GEODE-2601: Fixing banner being logged twice during...

[kirklund]

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

https://github.com/apache/geode/pull/571#discussion_r121188448
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/distributed/internal/InternalLocator.java
 ---
@@ -478,9 +478,8 @@ private InternalLocator(int port, File logF, File 
stateF, InternalLogWriter logW
 if (logWriter == null) {
   logWriter = LogWriterFactory.createLogWriterLogger(false, false, 
this.config,
   !startDistributedSystem);
-  if (logger.isDebugEnabled()) {
+  if (logger.isDebugEnabled())
--- End diff --

We've always had {'s in our style guidelines. So most of us are adding them 
in for small if-blocks rather than removing them.


---
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 59946: GEODE-3054: escaping the escape character in the command string before passing it to the SimpleParser

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On June 9, 2017, 2:57 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59946/
> ---
> 
> (Updated June 9, 2017, 2:57 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3054: escaping the escape character in the command string before 
> passing it to the SimpleParser
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  df16e9b9e9f71f21ef7c8ac84267a9858ee4298c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueAdapter.java
>  5c466a0c70c433d5f595cf3eab903fda8d362f9c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueConverter.java
>  e3e1fec243fcb2e4048c60510af52c799e9c5110 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  ab6dc3d10a6235af0ca6fc5164cac5d3c2419cdd 
> 
> 
> Diff: https://reviews.apache.org/r/59946/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successfull
> hydra test failures related to path name are fixed.
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59946: GEODE-3054: escaping the escape character in the command string before passing it to the SimpleParser

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On June 9, 2017, 2:57 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59946/
> ---
> 
> (Updated June 9, 2017, 2:57 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3054: escaping the escape character in the command string before 
> passing it to the SimpleParser
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  df16e9b9e9f71f21ef7c8ac84267a9858ee4298c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueAdapter.java
>  5c466a0c70c433d5f595cf3eab903fda8d362f9c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueConverter.java
>  e3e1fec243fcb2e4048c60510af52c799e9c5110 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  ab6dc3d10a6235af0ca6fc5164cac5d3c2419cdd 
> 
> 
> Diff: https://reviews.apache.org/r/59946/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successfull
> hydra test failures related to path name are fixed.
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Apache Jenkins Server]

See 

Re: Review Request 59850: GEODE-3023: TcpServer thread can be blocked in processRequest

[Udo Kohlmeyer]

> On June 9, 2017, 1:06 a.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
> > Lines 82 (patched)
> > 
> >
> > I'm missing the time delay here. Can you show me where it gets delayed?
> > 
> > ... ah, it looks like you copied this from `TcpServerJUnitTest`. Would 
> > you mind renaming this function to something that makes more sense in this 
> > context?

There used to be a delayed TcpServer, the method name did not change. Updating 
to something more meaningful.


> On June 9, 2017, 1:06 a.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
> > Lines 133 (patched)
> > 
> >
> > We can reasonably set a very small timeout here, even less than the 
> > timeout of the socket (since we're mocking it). That (and setting the 
> > timeout to some silly number like 31337) would also help us verify that 
> > we're mocking correctly.

This is the timeout on the client pool connection. Has no bearing on this test.


> On June 9, 2017, 1:06 a.m., Galen O'Sullivan wrote:
> > geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
> > Lines 143 (patched)
> > 
> >
> > What's the GemStoneAddition about?

Legacy code reuse. Not required anymore. It's mocked away.


- Udo


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


On June 8, 2017, 12:20 a.m., Udo Kohlmeyer wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59850/
> ---
> 
> (Updated June 8, 2017, 12:20 a.m.)
> 
> 
> Review request for geode, Alexander Murmann, Bruce Schuchardt, Galen 
> O'Sullivan, Hitesh Khamesra, and Brian Rowe.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Moved the socket.setSoTimeout setting to be before the SSL handshake. This is 
> to avoid the timeout to never be set in the case of a SSLException. Added a 
> test to test that the socket timeout is correctly set upon failure within the 
> SSL configuration and handshake.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/tcpserver/TcpServer.java
>  86fe53261 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TCPServerSSLJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/tcpserver/TcpServerJUnitTest.java
>  7c7a2b376 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/DelaySocketCreator.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59850/diff/2/
> 
> 
> Testing
> ---
> 
> Junit test - done
> precheckin - done
> 
> 
> Thanks,
> 
> Udo Kohlmeyer
> 
>

Review Request 59946: GEODE-3054: escaping the escape character in the command string before passing it to the SimpleParser

[Jinmei Liao]

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

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


Repository: geode


Description
---

GEODE-3054: escaping the escape character in the command string before passing 
it to the SimpleParser


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 df16e9b9e9f71f21ef7c8ac84267a9858ee4298c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueAdapter.java
 5c466a0c70c433d5f595cf3eab903fda8d362f9c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/MultipleValueConverter.java
 e3e1fec243fcb2e4048c60510af52c799e9c5110 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
 ab6dc3d10a6235af0ca6fc5164cac5d3c2419cdd 


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


Testing
---

precheckin successfull
hydra test failures related to path name are fixed.


Thanks,

Jinmei Liao

Re: Review Request 59852: GEODE-2632: make SecurityService immutable to improve client/server performance

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On June 8, 2017, 9:22 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59852/
> ---
> 
> (Updated June 8, 2017, 9:22 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Ken Howe, 
> and Patrick Rhomberg.
> 
> 
> Bugs: GEODE-2632
> https://issues.apache.org/jira/browse/GEODE-2632
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> See https://github.com/apache/geode/pull/450 for JMH benchmark 
> ClientCachePutBench. I increased the runtime of ClientCachePutBench from 30 
> minutes to 2 hours to get more accurate measurement. I'll update the "Testing 
> Done" section with performance numbers when that finishes running. My 
> measurements include current develop branch and feature/GEODE-2632-21.
> 
> The changes in this change-set involve making the SecurityService 
> implementation(s) immutable to improve performance of client/server as 
> measured by the JMH benchmark ClientCachePutBench.
> 
> Sorry it's such a long diff again -- I tried to shrink this one down. I could 
> leave out the bulk of client Command classes and tests -- let me know if this 
> review is too big and unwieldy.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  45e7a6139b30c800e6096d61d1f23db36c017f99 
>   geode-core/src/main/java/org/apache/geode/cache/CacheFactory.java 
> 38fdac692315153cda9b4956d0fbbf66fa8f6399 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/ClientCacheFactory.java
>  0d678ca4d08d100ac99266c5d550d9cee7a13ea3 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> e06949c94ab3dd861e9dc64089bec809b3568a6c 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> 4de1a95f9acdcdbc843a3412fd773c60910dc43a 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionManager.java
>  029e6377f56d80dd81e4cec430f106ac743e5178 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f33ee55f72dc61c4adc2ab3de5429a1607 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SecurityConfig.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberFactory.java
>  f324e3355e77cc64a8e1cce878b3c03ad4180106 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/MemberServices.java
>  60249663aad0a59f1d292d0c5336cac33e503204 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/GMSMemberFactory.java
>  bc94ab5afd3e6c9bb5deb9e0beed5f1f84d924fa 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/Services.java
>  1404b3b6f2a44aeaf3c76b99dad8a428b1b5d1f7 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  ab0ca6b4533a52528818ab3b8059576c0bd1518f 
>   geode-core/src/main/java/org/apache/geode/internal/ClassLoadUtil.java 
> 60d1d3968916697ae1bbac979f6ad5f4a6ad30bd 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractLRURegionMap.java
>  988be0a72b97cf6d67dd7dd930e229f6eb867166 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CacheServerImpl.java 
> 670c697c7f6c3d22a3c79d10be4e9c9929cd612b 
>   geode-core/src/main/java/org/apache/geode/internal/cache/DiskStoreImpl.java 
> 67fcce85c0f812e062f602e97d604dd39c0edd9f 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  5e352241ac114b891adb178e1820e8c74017fa64 
>   geode-core/src/main/java/org/apache/geode/internal/cache/InternalCache.java 
> d9a34e1cfa85cc08ff4f0af81b6adc2bdbd7e869 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java
>  037bff6ebd0f49b7afe6b5aad4c0edd9ca3b139a 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/partitioned/FetchEntriesMessage.java
>  489ffbaddabfc2d2a46d87d3060d5c61b76c7f32 
>   geode-core/src/main/java/org/apache/geode/internal/cache/tier/Command.java 
> d7f7c7b20372351963dbc6cb1e8bab506ffcc1d0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/AcceptorImpl.java
>  9658f98da808e50b87fe54854df249b28b97662d 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommand.java
>  1fb8c8cac62c54b582d40688a423fddcae23b36e 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java
>  

RE: Need information about FunctionStatistics

[Dinesh Akhand]

Hi Team,

Problem Solved ,

Function Stats works fine if function is associated with JVM . else it will 
display 0 .

Thanks,
Dinesh Akhand

From: Dinesh Akhand
Sent: Friday, June 9, 2017 4:34 PM
To: dev@geode.apache.org; 'bogle...@pivotal.io' 
Subject: RE: Need information about FunctionStatistics


Hi Barry,



Yes , I can see the function statics in VSD  but looks like



All the stats are 0 .  not even for single function stats are correct .



   FunctionExecution, 2265, FunctionServiceStatistics: "2017/06/07 12:11:09.201 
IDT" samples=502

  functionExecutionsCompleted operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0

  functionExecutionsCompletedProcessingTime nanoseconds/sec: samples=501 min=0 
max=190219.8 average=379.68 stddev=8498.39 last=0

  functionExecutionsRunning operations: samples=502 min=0 max=0 average=0 
stddev=0 last=0

  resultsSentToResultCollector operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0

  resultsReceived operations/sec: samples=501 min=0 max=0 average=0 stddev=0 
last=0

  functionExecutionCalls operations/sec: samples=501 min=0 max=0.2 average=0 
stddev=0.01 last=0

  functionExecutionsHasResultCompletedProcessingTime nanoseconds/sec: 
samples=501 min=0 max=190219.8 average=379.68 stddev=8498.39 last=0

  functionExecutionsHasResultRunning operations: samples=502 min=0 max=0 
average=0 stddev=0 last=0

  functionExecutionsExceptions operations/sec: samples=501 min=0 max=0 
average=0 stddev=0 last=0



Can you please confirm function stats values are correct in your case.



Thanks,

Dinesh Akhand



-Original Message-
From: Barry Oglesby [mailto:bogle...@pivotal.io]
Sent: Thursday, June 8, 2017 10:38 PM
To: dev@geode.apache.org
Subject: Re: Need information about FunctionStatistics



Dinesh,



The FunctionStatistics and FunctionServiceStatistics look to be displaying 
properly in vsd. Are you not seeing them?



Thanks,

Barry Oglesby





On Thu, Jun 8, 2017 at 9:51 AM, Kirk Lund 
> wrote:



> I think we would probably need to introduce a new

> FunctionServiceMXBean with these stats as attributes or add

> showFunctionMetrics() operation to MemberMXBean.

>

> On Wed, Jun 7, 2017 at 6:32 AM, Dinesh Akhand 
> > wrote:

>

> > Hi Team,

> >

> > Currently I can see Function stats are getting generated .

> > functionExecutionsCompleted operations/sec: samples=1955 min=0 max=0

> > average=0 stddev=0 last=0

> >   functionExecutionsCompletedProcessingTime nanoseconds/sec:

> samples=1955

> > min=0 max=0 average=0 stddev=0 last=0

> >   functionExecutionsRunning operations: samples=1956 min=0 max=0

> average=0

> > stddev=0 last=0

> >   resultsSentToResultCollector operations/sec: samples=1955 min=0

> > max=2.6

> > average=0 stddev=0.1 last=0

> >   resultsReceived operations/sec: samples=1955 min=0 max=2.6

> > average=0

> > stddev=0.1 last=0

> >   functionExecutionCalls operations/sec: samples=1955 min=0 max=0

> > average=0 stddev=0 last=0

> >

> > but I am not able to see them on JMX .

> >

> > I found last end point in  MemberMBeanBridge for JMX.   Is there any

> > information and document can you provide.

> > I want to publish FunctionStatistics on JMX , any suggestion will be

> > welcome.

> >

> >

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

> > https://www.amdocs.com/about/email-disclaimer>

> >

>
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 

Build failed in Jenkins: Geode-release-flaky #10

[Apache Jenkins Server]

See 

--
[...truncated 88.84 KB...]
Download 
https://repo1.maven.org/maven2/org/springframework/ldap/spring-ldap-core/2.3.1.RELEASE/spring-ldap-core-2.3.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-config/4.2.1.RELEASE/spring-security-config-4.2.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-ldap/4.2.1.RELEASE/spring-security-ldap-4.2.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-web/4.2.1.RELEASE/spring-security-web-4.2.1.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-tx/4.3.6.RELEASE/spring-tx-4.3.6.RELEASE.jar
Download 
https://repo1.maven.org/maven2/org/springframework/security/spring-security-core/4.2.1.RELEASE/spring-security-core-4.2.1.RELEASE.jar
Note: 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-pulse:copyGemFireVersionFile
:geode-pulse:processResources
:geode-pulse:classes
:geode-rebalancer:compileJava
:geode-rebalancer:processResources UP-TO-DATE
:geode-rebalancer:classes
:geode-wan:compileJava
:geode-wan:processResources
:geode-wan:classes
:geode-web:compileJava UP-TO-DATE
:geode-web:processResources UP-TO-DATE
:geode-web:classes UP-TO-DATE
:geode-web-api:compileJava
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-modules-base/2.8.6/jackson-modules-base-2.8.6.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/jackson-bom/2.8.6/jackson-bom-2.8.6.pom
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.pom
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-project/1.5.10/swagger-project-1.5.10.pom
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-models/1.5.10/swagger-models-1.5.10.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spi/2.6.1/springfox-spi-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-schema/2.6.1/springfox-schema-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-common/2.6.1/springfox-swagger-common-2.6.1.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-spring-web/2.6.1/springfox-spring-web-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/classmate/1.3.1/classmate-1.3.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-core/1.2.0.RELEASE/spring-plugin-core-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin/1.2.0.RELEASE/spring-plugin-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/springframework/plugin/spring-plugin-metadata/1.2.0.RELEASE/spring-plugin-metadata-1.2.0.RELEASE.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct/1.0.0.Final/mapstruct-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/org/mapstruct/mapstruct-parent/1.0.0.Final/mapstruct-parent-1.0.0.Final.pom
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer/2.8/paranamer-2.8.pom
Download 
https://repo1.maven.org/maven2/com/thoughtworks/paranamer/paranamer-parent/2.8/paranamer-parent-2.8.pom
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-core/2.6.1/springfox-core-2.6.1.pom
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-scala_2.10/2.8.6/jackson-module-scala_2.10-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger2/2.6.1/springfox-swagger2-2.6.1.jar
Download 
https://repo1.maven.org/maven2/io/springfox/springfox-swagger-ui/2.6.1/springfox-swagger-ui-2.6.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/hateoas/spring-hateoas/0.23.0.RELEASE/spring-hateoas-0.23.0.RELEASE.jar
Download 
https://repo1.maven.org/maven2/com/fasterxml/jackson/module/jackson-module-paranamer/2.8.6/jackson-module-paranamer-2.8.6.jar
Download 
https://repo1.maven.org/maven2/io/swagger/swagger-annotations/1.5.10/swagger-annotations-1.5.10.jar
Download 

RE: Need information about FunctionStatistics

[Dinesh Akhand]

Hi Barry,



Yes , I can see the function statics in VSD  but looks like



All the stats are 0 .  not even for single function stats are correct .



   FunctionExecution, 2265, FunctionServiceStatistics: "2017/06/07 12:11:09.201 
IDT" samples=502

  functionExecutionsCompleted operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0

  functionExecutionsCompletedProcessingTime nanoseconds/sec: samples=501 min=0 
max=190219.8 average=379.68 stddev=8498.39 last=0

  functionExecutionsRunning operations: samples=502 min=0 max=0 average=0 
stddev=0 last=0

  resultsSentToResultCollector operations/sec: samples=501 min=0 max=0.2 
average=0 stddev=0.01 last=0

  resultsReceived operations/sec: samples=501 min=0 max=0 average=0 stddev=0 
last=0

  functionExecutionCalls operations/sec: samples=501 min=0 max=0.2 average=0 
stddev=0.01 last=0

  functionExecutionsHasResultCompletedProcessingTime nanoseconds/sec: 
samples=501 min=0 max=190219.8 average=379.68 stddev=8498.39 last=0

  functionExecutionsHasResultRunning operations: samples=502 min=0 max=0 
average=0 stddev=0 last=0

  functionExecutionsExceptions operations/sec: samples=501 min=0 max=0 
average=0 stddev=0 last=0



Can you please confirm function stats values are correct in your case.



Thanks,

Dinesh Akhand



-Original Message-
From: Barry Oglesby [mailto:bogle...@pivotal.io]
Sent: Thursday, June 8, 2017 10:38 PM
To: dev@geode.apache.org
Subject: Re: Need information about FunctionStatistics



Dinesh,



The FunctionStatistics and FunctionServiceStatistics look to be displaying 
properly in vsd. Are you not seeing them?



Thanks,

Barry Oglesby





On Thu, Jun 8, 2017 at 9:51 AM, Kirk Lund 
> wrote:



> I think we would probably need to introduce a new

> FunctionServiceMXBean with these stats as attributes or add

> showFunctionMetrics() operation to MemberMXBean.

>

> On Wed, Jun 7, 2017 at 6:32 AM, Dinesh Akhand 
> > wrote:

>

> > Hi Team,

> >

> > Currently I can see Function stats are getting generated .

> > functionExecutionsCompleted operations/sec: samples=1955 min=0 max=0

> > average=0 stddev=0 last=0

> >   functionExecutionsCompletedProcessingTime nanoseconds/sec:

> samples=1955

> > min=0 max=0 average=0 stddev=0 last=0

> >   functionExecutionsRunning operations: samples=1956 min=0 max=0

> average=0

> > stddev=0 last=0

> >   resultsSentToResultCollector operations/sec: samples=1955 min=0

> > max=2.6

> > average=0 stddev=0.1 last=0

> >   resultsReceived operations/sec: samples=1955 min=0 max=2.6

> > average=0

> > stddev=0.1 last=0

> >   functionExecutionCalls operations/sec: samples=1955 min=0 max=0

> > average=0 stddev=0 last=0

> >

> > but I am not able to see them on JMX .

> >

> > I found last end point in  MemberMBeanBridge for JMX.   Is there any

> > information and document can you provide.

> > I want to publish FunctionStatistics on JMX , any suggestion will be

> > welcome.

> >

> >

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

> > https://www.amdocs.com/about/email-disclaimer>

> >

>
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 

Build failed in Jenkins: Geode-release #59

[Apache Jenkins Server]

See 


Changes:

[jstewart] GEODE-3032: Fix CI failure of CommandOverHttpDUnitTest

[dbarnes] GEODE-3029: Tomcat Install Documentation has incorrect required JARs

--
[...truncated 111.80 KB...]
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:272)
at 
org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2815)
at 
org.apache.geode.internal.cache.ProxyBucketRegion.recoverFromDisk(ProxyBucketRegion.java:423)
at 
org.apache.geode.internal.cache.ProxyBucketRegion.recoverFromDiskRecursively(ProxyBucketRegion.java:389)
at 
org.apache.geode.internal.cache.PRHARedundancyProvider$4.run2(PRHARedundancyProvider.java:1736)
at 
org.apache.geode.internal.cache.partitioned.RecoveryRunnable.run(RecoveryRunnable.java:61)
at 
org.apache.geode.internal.cache.PRHARedundancyProvider$4.run(PRHARedundancyProvider.java:1728)
at java.lang.Thread.run(Thread.java:745)

6897 tests completed, 1 failed, 604 skipped
:geode-core:distributedTest FAILED
:geode-core:integrationTest

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesRegionsUsingSystemProperty FAILED
java.lang.RuntimeException: Could not start Server
at 
org.apache.geode.redis.GeodeRedisServer.start(GeodeRedisServer.java:387)
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesRegionsUsingSystemProperty(RedisServerTest.java:78)

Caused by:
java.net.BindException: Address already in use

java.lang.NullPointerException
at 
org.apache.geode.redis.GeodeRedisServer.shutdown(GeodeRedisServer.java:629)
at 
org.apache.geode.redis.RedisServerTest.teardown(RedisServerTest.java:46)

org.apache.geode.redis.RedisServerTest > initializeRedisCreatesThreeRegions 
FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesThreeRegions(RedisServerTest.java:54)

org.apache.geode.redis.RedisServerTest > 
initializeRedisCreatesPartitionedRegionByDefault FAILED
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesPartitionedRegionByDefault(RedisServerTest.java:64)

3567 tests completed, 3 failed, 163 skipped
:geode-core:integrationTest FAILED
: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:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
: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