Build failed in Jenkins: Geode-release #43

[Apache Jenkins Server]

See 

Changes:

[upthewaterspout] GEODE-2386 Don't call System.setProperties(null) when rule is 
used twice

--
[...truncated 1861 lines...]
:geode-json:testClasses UP-TO-DATE
: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:flakyTest 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:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.0.0/lucene-test-framework-6.0.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.0.0/lucene-codecs-6.0.0.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.3.2/randomizedtesting-runner-2.3.2.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-parent/2.3.2/randomizedtesting-parent-2.3.2.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.0.0/lucene-test-framework-6.0.0.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.0.0/lucene-codecs-6.0.0.jar
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.3.2/randomizedtesting-runner-2.3.2.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-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:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
: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:flakyTest
: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
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJava
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-api/2.53.1/selenium-api-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-parent/2.53.1/selenium-parent-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-remote-driver/2.53.1/selenium-remote-driver-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-support/2.53.1/selenium-support-2.53.1.pom
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.2.RELEASE/spring-test-4.3.2.RELEASE.pom
Download https://repo1.maven.org/maven2/com/tdunning/json/1.7/json-1.7.pom
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-api/2.53.1/selenium-api-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-remote-driver/2.53.1/selenium-remote-driver-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/seleniumhq/selenium/selenium-support/2.53.1/selenium-support-2.53.1.jar
Download 
https://repo1.maven.org/maven2/org/springframework/spring-test/4.3.2.RELEASE/spring-test-4.3.2.RELEASE.jar
Download https://repo1.maven.org/maven2/com/tdunning/json/1.7/json-1.7.jar
Note: 

 

[jira] [Commented] (GEODE-2411) Remove references to Gemfire from include guards

[ASF GitHub Bot (JIRA)]

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

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

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/387
  
The convention in this pull request is not consistent with the Google C++ 
Style Guide.

https://google.github.io/styleguide/cppguide.html#The__define_Guard



> Remove references to Gemfire from include guards
> 
>
> Key: GEODE-2411
> URL: https://issues.apache.org/jira/browse/GEODE-2411
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Many of the macro definitions used as include guards in the C++ header files 
> refer to Gemfire. These references should be replaced at least with 
> references to Geode but preferably using pragmas instead of defines.



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

[GitHub] geode issue #387: GEODE-2411: Remove references to Gemfire from include guar...

[pivotal-jbarrett]

Github user pivotal-jbarrett commented on the issue:

https://github.com/apache/geode/pull/387
  
The convention in this pull request is not consistent with the Google C++ 
Style Guide.

https://google.github.io/styleguide/cppguide.html#The__define_Guard



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

[Dan Smith]

One thing Hitesh and I noticed is that when you do a build, it creates a
directory called geode-old-versions because there is a line in
settings.gradle for a geode-old-versions project.

Is this leftover cruft, or is it actually supposed to be there? I see a
couple of references to geode-old-versions in the source as well.

-Dan

[VOTE] RC1: Apache Geode release - v1.1.0

[Hitesh Khamesra]

All,

This is the first release candidate of the first release for Apache Geode, 
version 1.1.0.
Thanks to all the community members.

It fixes the following issues:
   
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12338352


*** Please download, test and vote by Wednesday, February 08, 0800 hrs US 
Pacific.

Note that we are voting upon the source (tag):
   rel/v1.1.0.RC1
   
https://git-wip-us.apache.org/repos/asf?p=geode.git;a=tag;h=refs/tags/rel/v1.1.0.RC1

Commit ID: 90760d334f912cef49ad32f275aed9cd9f1f2688
   
Source and binary files:
   https://dist.apache.org/repos/dist/dev/geode/1.1.0.RC1/

Maven staging repo:
   https://repository.apache.org/content/repositories/orgapachegeode-1015/

Geode's KEYS file containing PGP keys we use to sign the release:
   https://github.com/apache/geode/blob/release/1.1.0/KEYS

pub   4096R/AC6AB8ED 2017-01-18
  Key fingerprint = 048F B40F AD7D 9C15 54AD  D447 2CA9 90A2 AC6A B8ED

Thanks,
Dan & Hitesh (on behalf of the Geode team)

[jira] [Commented] (GEODE-2411) Remove references to Gemfire from include guards

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PivotalSarge opened a pull request:

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

GEODE-2411: Remove references to Gemfire from include guards

In the process of replacing references to Gemfire with references to Apache 
Geode in the include guards, standardize the include guards and use #pragma 
once where applicable.

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

$ git pull https://github.com/PivotalSarge/geode feature/GEODE-2411

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

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


commit 3fc6b70429c2a4e247c164d7ad86ea0c0177b0a0
Author: Sarge 
Date:   2017-02-01T21:00:14Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 435f6bcf3edbf5e45bb404dee57f322ed4851649
Author: Sarge 
Date:   2017-02-01T21:15:40Z

GEODE-2411: Add missing #pragma once.

commit d2d4db0373f94cf12a6ab9b5265a29d8bb71838c
Author: Sarge 
Date:   2017-02-02T21:55:23Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 17181d074aa9ca1e9b759b18a17d6020ad57c93f
Author: Sarge 
Date:   2017-02-02T23:31:49Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit c36f963ad8613534ebff87de2425a5eaa7992cc7
Author: Sarge 
Date:   2017-02-03T16:38:31Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 2c990d1be22ba9fa4bc4d096b44a5c1a9d633dc8
Author: Sarge 
Date:   2017-02-03T17:13:12Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit e05b3e1a643cb54828d20a768f8c9e96a6e47c63
Author: Sarge 
Date:   2017-02-03T19:01:07Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit e051494fde181b431caf2501894f764820e02450
Author: Sarge 
Date:   2017-02-03T19:09:29Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 414a91e712149e417dd421fa6a8307b2e3c7c95d
Author: Sarge 
Date:   2017-02-03T21:28:03Z

GEODE-2411: Fix collateral damage from scripting.

commit e376e56d90a582482bd117a774b0085b127a4448
Author: Sarge 
Date:   2017-02-03T23:38:20Z

GEODE-2411: Add back include guards for Solaris.




> Remove references to Gemfire from include guards
> 
>
> Key: GEODE-2411
> URL: https://issues.apache.org/jira/browse/GEODE-2411
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Michael Dodge
>Assignee: Michael Dodge
>
> Many of the macro definitions used as include guards in the C++ header files 
> refer to Gemfire. These references should be replaced at least with 
> references to Geode but preferably using pragmas instead of defines.



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

[GitHub] geode pull request #387: GEODE-2411: Remove references to Gemfire from inclu...

[PivotalSarge]

GitHub user PivotalSarge opened a pull request:

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

GEODE-2411: Remove references to Gemfire from include guards

In the process of replacing references to Gemfire with references to Apache 
Geode in the include guards, standardize the include guards and use #pragma 
once where applicable.

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

$ git pull https://github.com/PivotalSarge/geode feature/GEODE-2411

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

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


commit 3fc6b70429c2a4e247c164d7ad86ea0c0177b0a0
Author: Sarge 
Date:   2017-02-01T21:00:14Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 435f6bcf3edbf5e45bb404dee57f322ed4851649
Author: Sarge 
Date:   2017-02-01T21:15:40Z

GEODE-2411: Add missing #pragma once.

commit d2d4db0373f94cf12a6ab9b5265a29d8bb71838c
Author: Sarge 
Date:   2017-02-02T21:55:23Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 17181d074aa9ca1e9b759b18a17d6020ad57c93f
Author: Sarge 
Date:   2017-02-02T23:31:49Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit c36f963ad8613534ebff87de2425a5eaa7992cc7
Author: Sarge 
Date:   2017-02-03T16:38:31Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 2c990d1be22ba9fa4bc4d096b44a5c1a9d633dc8
Author: Sarge 
Date:   2017-02-03T17:13:12Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit e05b3e1a643cb54828d20a768f8c9e96a6e47c63
Author: Sarge 
Date:   2017-02-03T19:01:07Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit e051494fde181b431caf2501894f764820e02450
Author: Sarge 
Date:   2017-02-03T19:09:29Z

GEODE-2411: Replace Gemfire-related include guards with #pragma once.

commit 414a91e712149e417dd421fa6a8307b2e3c7c95d
Author: Sarge 
Date:   2017-02-03T21:28:03Z

GEODE-2411: Fix collateral damage from scripting.

commit e376e56d90a582482bd117a774b0085b127a4448
Author: Sarge 
Date:   2017-02-03T23:38:20Z

GEODE-2411: Add back include guards for Solaris.




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

[jira] [Assigned] (GEODE-1964) Add docs for native client to develop branch

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-1964:
--

Assignee: Dave Barnes

> Add docs for native client to develop branch
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

[jira] [Commented] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2386:


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

GEODE-2386 Don't call System.setProperties(null) when rule is used twice

Fixing DistributedRestoreSystemProperties rule so that if the rule is
included twice within a test, it does not end up calling
System.setProperties(null). That will prevent us from losing the value
of java.class.path set by gradle.

Reverting the workaround that didn't actually work.


> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: build, tests
>Reporter: Dan Smith
>Assignee: Dan Smith
> Fix For: 1.1.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> 

[jira] [Commented] (GEODE-1672) When amount of overflowed persisted data exceeds heap size startup may run out of memory

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1672:


Commit 086df14b0dce92c5dd0678f36879533d310d9a37 in geode's branch 
refs/heads/feature/GEODE-2267 from [~agingade]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=086df14 ]

GEODE-1672: Added recovery wait for all the regions created to
address race condition in the test.


> When amount of overflowed persisted data exceeds heap size startup may run 
> out of memory
> 
>
> Key: GEODE-1672
> URL: https://issues.apache.org/jira/browse/GEODE-1672
> Project: Geode
>  Issue Type: Bug
>  Components: docs, persistence
>Reporter: Darrel Schneider
>
> Basically, when the amount of data overflowed approaches the heap size, ,such 
> that the total amount of data is very close to or actually surpasses your 
> total tenured heap, it is possible that you will not be able to restart.
> The algorithm during recovery of oplogs/buckets is such that we don't "evict" 
> in the normal sense as data fills the heap during early stages of recovery 
> prior to creating the regions. When the data is first created in the heap, 
> it's not yet official in the region.
> At any rate, if during this early phase of recovery, or during subsequent 
> phase where eviction is working as usual, it is possible that the total data 
> or an early imbalance of buckets prior to the opportunity to rebalance causes 
> us to surpass the critical threshold which will kill us before successful 
> startup.
> To reproduce, you could have 1 region with tons of data that evicts and 
> overflows with persistence. Call it R1. Then another region with persistence 
> that does not evict. Call it R2.
> List R1 fist in the cache.xml file. Start running the system and add data 
> over time until you have overflowed tons of data approaching the heap size in 
> the evicted region, and also have enough data in the R2 region.
> Once you fill these regions with enough data and have overflowed enough to 
> disk and persisted the other region, then shutdown, and then attempt to 
> restart. If you put enough data in, you will hit the critical threshold 
> before being able to complete startup.
> You can work around this issue by configuring geode to not recovery values by 
> setting this system property: -Dgemfire.disk.recoverValues=false
> Values will not be faulted into memory until a read operation is done on that 
> value's key.
> If you have regions that do not use overflow and some that do then another 
> work around is the create the regions that do not use overflow first. 



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

Re: [DISCUSS] Release branch for 1.1.0

[Hitesh Khamesra]

Thanks, I have moved this out from 1.1.0.
-Hitesh


  From: Anilkumar Gingade 
 To: dev@geode.apache.org 
 Sent: Friday, February 3, 2017 2:44 PM
 Subject: Re: [DISCUSS] Release branch for 1.1.0
   
Agree, no need to push changes in hurry...

-Anil.


On Fri, Feb 3, 2017 at 2:33 PM, Dan Smith  wrote:

> +1 for pushing out GEODE-2413. I think what Anthony said makes sense.
>
> -Dan
>
> On Fri, Feb 3, 2017 at 2:32 PM, Anthony Baker  wrote:
>
> >
> > > On Feb 3, 2017, at 2:03 PM, Hitesh Khamesra
> 
> > wrote:
> > >
> > >  GEODE-2413 : Implementing a peer-to-peer protocol for mutual auth
> > require some more investigation. Apart from that, we need to support
> > backward compatibility as well.  Considering the complexity of the issue,
> > would it make sense to move that out of 1.1.0 release?
> > >
> > > Thoughts?
> > >
> >
> > Sounds like it has the potential to destabilize the release branch.  I
> > think we should move it out of the release so we can take the time to
> > properly develop tests and discuss the best solution.
> >
> > Anthony
> >
> >
>


   

[Spring CI] Spring Data GemFire > Nightly-ApacheGeode > #460 has FAILED (11 tests failed, no failures were new)

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #460 failed.
---
Scheduled
11/1666 tests failed, no failures were new.

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

-
Currently Responsible
-

John Blum 



--
Failing Jobs
--
  - Default Job (Default Stage): 11 of 1666 tests failed.




--
Tests
--
Existing Test Failures (11)
   - ClientSubRegionTest: Org.springframework.data.gemfire.client. client sub 
region test
   - GemFireDataSourceTest: Org.springframework.data.gemfire.client. gem fire 
data source test
   - GemFireDataSourceWithLocalRegionTest: 
Org.springframework.data.gemfire.client. gem fire data source with local region 
test
   - ContinuousQueryListenerContainerNamespaceTest: 
Org.springframework.data.gemfire.config.xml. continuous query listener 
container namespace test
   - ClientCacheFunctionExecutionWithPdxIntegrationTest: 
Org.springframework.data.gemfire.function. client cache function execution with 
pdx integration test
   - FunctionExecutionTests: 
Org.springframework.data.gemfire.function.execution. function execution tests
   - FunctionIntegrationTests: 
Org.springframework.data.gemfire.function.execution. function integration tests
   - GemfireFunctionTemplateTests: 
Org.springframework.data.gemfire.function.execution. gemfire function template 
tests
   - ListenerContainerTests: Org.springframework.data.gemfire.listener. 
listener container tests
   - ContainerXmlSetupTest: Org.springframework.data.gemfire.listener.adapter. 
container xml setup test
   - RepositoryClientRegionTests: 
Org.springframework.data.gemfire.repository.config. repository client region 
tests
Fixed Tests (1)
   - ApacheShiroRealmGeodeSecurityIntegrationTests: Authorized user

--
This message is automatically generated by Atlassian Bamboo

Re: [DISCUSS] Release branch for 1.1.0

[Anilkumar Gingade]

Agree, no need to push changes in hurry...

-Anil.


On Fri, Feb 3, 2017 at 2:33 PM, Dan Smith  wrote:

> +1 for pushing out GEODE-2413. I think what Anthony said makes sense.
>
> -Dan
>
> On Fri, Feb 3, 2017 at 2:32 PM, Anthony Baker  wrote:
>
> >
> > > On Feb 3, 2017, at 2:03 PM, Hitesh Khamesra
> 
> > wrote:
> > >
> > >  GEODE-2413 : Implementing a peer-to-peer protocol for mutual auth
> > require some more investigation. Apart from that, we need to support
> > backward compatibility as well.  Considering the complexity of the issue,
> > would it make sense to move that out of 1.1.0 release?
> > >
> > > Thoughts?
> > >
> >
> > Sounds like it has the potential to destabilize the release branch.  I
> > think we should move it out of the release so we can take the time to
> > properly develop tests and discuss the best solution.
> >
> > Anthony
> >
> >
>

[jira] [Updated] (GEODE-2413) peer-to-peer authentication: Peer need to re-authenticate coordinator while accepting view message

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2413:
---
Fix Version/s: (was: 1.1.0)
   1.2.0

> peer-to-peer authentication: Peer need to re-authenticate coordinator while 
> accepting view message
> --
>
> Key: GEODE-2413
> URL: https://issues.apache.org/jira/browse/GEODE-2413
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.2.0
>
>
> In peer-to-peer authentication, coordinator authenticates the joining member. 
> Then coordinator includes that new member in the cluster and sends new view 
> message. This view message should include coordinator's credential so that 
> joining member can authenticate coordinator as well (i.e. mutual 
> authentication)



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

[jira] [Updated] (GEODE-1434) Update native client source headers

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-1434:
-
Attachment: rat.out.gz

Here's the current rat report.  Most of the src files have been done, but we 
need to clean up scripts, xml, etc.

> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
> Attachments: rat.out.gz
>
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



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

[jira] [Updated] (GEODE-1964) Add docs for native client to develop branch

[Anthony Baker (JIRA)]

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

Anthony Baker updated GEODE-1964:
-
Issue Type: Bug  (was: Sub-task)
Parent: (was: GEODE-1416)

> Add docs for native client to develop branch
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

[jira] [Commented] (GEODE-1964) Add docs for native client to develop branch

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-1964:
--

I'm going to move this subtask to a linked top-level task.

> Add docs for native client to develop branch
> 
>
> Key: GEODE-1964
> URL: https://issues.apache.org/jira/browse/GEODE-1964
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Dave Barnes
>
> After the native client code has been merged to develop, the documentation 
> should follow. This subtask allows us to 'park' the existing docs on a 
> feature branch until they're needed.



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

[jira] [Resolved] (GEODE-1432) Create c++ client example application

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1432.
--
Resolution: Invalid

This task is not required for merging the native client to develop.

> Create c++ client example application
> -
>
> Key: GEODE-1432
> URL: https://issues.apache.org/jira/browse/GEODE-1432
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should create a simple HelloWorld application to show how to use the c++ 
> client libraries to connect to a Geode cluster.



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

[jira] [Assigned] (GEODE-1434) Update native client source headers

[Anthony Baker (JIRA)]

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

Anthony Baker reassigned GEODE-1434:


Assignee: Anthony Baker

> Update native client source headers
> ---
>
> Key: GEODE-1434
> URL: https://issues.apache.org/jira/browse/GEODE-1434
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Anthony Baker
>
> The existing native client source code headers contain { pivotal | vmware | 
> gemstone } copyrights and should be replaced with ASF headers.  See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Files without a source header probably need the ASF header added.  Only in 
> exceptional circumstances should a file not have a source header.



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

[jira] [Closed] (GEODE-1433) Create .NET client example application

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1433.


> Create .NET client example application
> --
>
> Key: GEODE-1433
> URL: https://issues.apache.org/jira/browse/GEODE-1433
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should create a simple HelloWorld application to show how to use the .NET 
> client libraries to connect to a Geode cluster.



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

[jira] [Closed] (GEODE-1432) Create c++ client example application

[Anthony Baker (JIRA)]

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

Anthony Baker closed GEODE-1432.


> Create c++ client example application
> -
>
> Key: GEODE-1432
> URL: https://issues.apache.org/jira/browse/GEODE-1432
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should create a simple HelloWorld application to show how to use the c++ 
> client libraries to connect to a Geode cluster.



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

[jira] [Resolved] (GEODE-1433) Create .NET client example application

[Anthony Baker (JIRA)]

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

Anthony Baker resolved GEODE-1433.
--
Resolution: Invalid

This task is not required for merging the native client to develop.

> Create .NET client example application
> --
>
> Key: GEODE-1433
> URL: https://issues.apache.org/jira/browse/GEODE-1433
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>
> We should create a simple HelloWorld application to show how to use the .NET 
> client libraries to connect to a Geode cluster.



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

[GitHub] geode pull request #386: Feature/geode 2421

[echobravopapa]

Github user echobravopapa closed the pull request at:

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


---
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] Release branch for 1.1.0

[Dan Smith]

+1 for pushing out GEODE-2413. I think what Anthony said makes sense.

-Dan

On Fri, Feb 3, 2017 at 2:32 PM, Anthony Baker  wrote:

>
> > On Feb 3, 2017, at 2:03 PM, Hitesh Khamesra 
> wrote:
> >
> >  GEODE-2413 : Implementing a peer-to-peer protocol for mutual auth
> require some more investigation. Apart from that, we need to support
> backward compatibility as well.  Considering the complexity of the issue,
> would it make sense to move that out of 1.1.0 release?
> >
> > Thoughts?
> >
>
> Sounds like it has the potential to destabilize the release branch.  I
> think we should move it out of the release so we can take the time to
> properly develop tests and discuss the best solution.
>
> Anthony
>
>

[jira] [Commented] (GEODE-2421) Create VS2015 AMI

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2421:


Commit 826e77384b9b97cda47cc021a645da459fbb56cf in geode's branch 
refs/heads/next-gen-native-client-software-grant from [~eburghardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=826e773 ]

GEODE-2421: fix install of vs2015 to use PowerShell Install-Package

This closes #386


> Create VS2015 AMI
> -
>
> Key: GEODE-2421
> URL: https://issues.apache.org/jira/browse/GEODE-2421
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Ernest Burghardt
>




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

Re: geode git commit: GEODE-2421: Adding packer portion of making a VS2015 dev AMI

[Dan Smith]

There is another PR on these packer scripts. I'm going to go ahead and
merge the changes, given that it sounds like we're working towards a readme
and making these scripts useful to everyone in the community. If there are
objections, I can stop accepting these PRs.

-Dan

On Thu, Feb 2, 2017 at 7:47 PM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> +1 for packer scripts. With Jake's readme everyone should be able to use
> it as a standard way to build environment for the native client.
>
> Thanks for sharing that!
>
> Sent from my iPhone
>
> > On Feb 2, 2017, at 7:20 PM, Michael Martell  wrote:
> >
> > For those unfamiliar with packer, or looking for the simplest path to
> > building and learning the code, it may be advantageous to post the steps
> > for each platform. Personally, I like to learn new code by stepping thru
> > examples in the debugger. I'd be happy to post my setup for debugging the
> > Geode C++ client on Windows 10 with Visual Studio and OSX with Xcode.
> >
> > Mike
> >
> >> On Thu, Feb 2, 2017 at 4:41 PM Jacob Barrett 
> wrote:
> >>
> >> I have a readme started that I will commit when I am back from vacation
> in
> >> a week.
> >> On Thu, Feb 2, 2017 at 4:36 PM Anthony Baker  wrote:
> >>
> >>> +1 for a README
> >>>
> >>> I started on a Dockerfile so we could run a job on builds.apache.org.
> I
> >>> haven’t been able to get back to it recently but here’s a rough draft:
> >>>
> >>> FROM ubuntu
> >>> MAINTAINER Apache Geode Geode 
> >>>
> >>> ARG GEODE_VERSION
> >>>
> >>> RUN \
> >>>  apt-get update && \
> >>>  apt-get -y upgrade && \
> >>>  apt-get install -y build-essential && \
> >>>  apt-get install -y cmake && \
> >>>  apt-get install -y doxygen && \
> >>>  apt-get install -y git && \
> >>>  apt-get install -y openjdk-8-jdk && \
> >>>  apt-get install -y wget && \
> >>>  apt-get install -y zlib1g-dev && \
> >>>  rm -rf /var/lib/apt/lists/*
> >>>
> >>> RUN \
> >>>  wget
> >>>
> >> https://builds.apache.org/job/Geode-nightly/
> lastSuccessfulBuild/artifact/geode-assembly/build/
> distributions/apache-geode-${GEODE_VERSION}.tar.gz
> >>> && \
> >>>  tar xzf apache-geode-${GEODE_VERSION}.tar.gz && \
> >>>  ls /
> >>>  #rm apache-geode-${GEODE_VERSION.tar}.tar.gz
> >>>
> >>> ENV GEODE /apache-geode-${GEODE_VERSION}
> >>> ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64
> >>>
> >>> CMD ["bash"]
> >>>
> >>>
> >>> As far as releases go, I think we should start with a source-only
> release
> >>> (after all that’s the only *officially* recognized artifact anyway).
> If
> >> we
> >>> want to create binary convenience artifacts for a release, I would be
> >>> hesitant to go beyond linux because multi-platforms builds impose a
> large
> >>> burden on the Release Manager.
> >>>
> >>> Anthony
> >>>
>  On Feb 2, 2017, at 4:26 PM, Dan Smith  wrote:
> 
>  It does seem like this stuff needs a README on how to use it.
> 
>  Are we going to need these images do a release of the native client
> >> code?
>  How many of these platforms will we need to build on to release the
> >>> native
>  client?
> 
>  -Dan
> 
>  On Thu, Feb 2, 2017 at 3:43 PM, Jacob Barrett 
> >>> wrote:
> 
> > Think of it as a Dockerfile for things not Docker, like Solaris and
> > Windows. It describes and can build a machine capable of compile or
> > developing the native client. The toolchain is slightly more
> >> complicated
> > than the Java side. Currently the Packer files are implemented for
> AWS
> >>> but
> > can easily be modified to support other virtualization platforms like
> > VMWare, OpenStack, etc.
> >
> > -Jake
> >
> >
> > On Thu, Feb 2, 2017 at 3:38 PM Ernest Burghardt <
> >> eburgha...@pivotal.io>
> > wrote:
> >
> >> Hi Mark,
> >>
> >> Our thinking was to make our packer (and associated) scripts
> >> available
> > such
> >> that a community member could use them to create a VM that would be
> >>> very
> >> equivalent to our build environment.
> >> There is some info/documentation that would need to be created to
> >> show
> > how
> >> to do this, but it should be possible for an individual to make
> >> images
> > like
> >> we do in our pipeline.
> >>
> >> Best,
> >> Ernie
> >>
> >> On Thu, Feb 2, 2017 at 3:07 PM, Mark Bretl 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> How does/will this help the community?
> >>>
> >>> --Mark
> >>>
>  On Thu, Feb 2, 2017 at 2:25 PM, 
> wrote:
> 
>  Repository: geode
>  Updated Branches:
>  refs/heads/next-gen-native-client-software-grant e79c4072b ->
> >>> 340f2fca8
> 
> 
>  GEODE-2421: Adding packer portion of making a VS2015 dev AMI
> 
> 

Re: JIRA access request

[Mark Bretl]

Hi Ernie,

I have added you to the Geode project. Thanks for joining!

--Mark

On Fri, Feb 3, 2017 at 2:08 PM, Ernest Burghardt 
wrote:

> Hello,
>
> May I please be added to Contributor on the Geode JIRA?
>
> Thanks in advance,
> Ernie
>

JIRA access request

[Ernest Burghardt]

Hello,

May I please be added to Contributor on the Geode JIRA?

Thanks in advance,
Ernie

Re: JMXMBeanDUnitTest and SSL properties

[Udo Kohlmeyer]

When we wrote these tests (many moons ago) we ran into this problem.

At that stage we could not establish what that cause of this failure 
was. BUT we (you and I) noted that behavior and marked it as flaky, in 
order to make sure it ran and at least tested the functionality.


--Udo


On 2/3/17 13:41, Kirk Lund wrote:

JMXMBeanDUnitTest has tests using SSL, not using SSL, configuring SSL with
the old legacy config properties, configuring SSL with the new config
properties.

One test is currently marked as a FlakyTest: testJMXOverLegacySSL

But it isn't a FlakyTest. By itself in fresh JVMs, testJMXOverLegacySSL
passes 100% but if I run this test with the other tests
in JMXMBeanDUnitTest it fails 100%. It always runs last (coincidence) and
it apparently fails because a previous test has configured SSL in some way.

I've tried adding "disconnectAllFromDS()" to tearDown but it still fails. I
believe there's some static either in Geode code or JDK code that gets a
value stuck in it from a previous test so that this test cannot pass.

I tried adding "invokeInEveryVM(() -> SocketCreatorFactory.close());" to
tearDown but it fails as well.

I filed GEODE-2427 to better describe the problem since it's not really a
Flaky test. JMXMBeanDUnitTest is an example of a test that we have marked
as Flaky because when we run it via flakyTest, it gets fresh unused dunit
JVMs. This really isn't the purpose of "FlakyTest" and this means we have
some static somewhere that's getting stuck and I simply cannot find that
static (or maybe it's a JDK bug or maybe it's something entirely different).

Any idea what's preventing this test from passing. Below is the full stack
of the failure when I run it with other tests:

org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
10.118.33.232 with 4 VMs

at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
at
org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:147)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
at
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.io.IOException: Failed to retrieve RMIServer stub:
javax.naming.CommunicationException [Root exception is
java.rmi.ConnectIOException: error during JRMP connection establishment;
nested exception is:
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:

Re: JMXMBeanDUnitTest and SSL properties

[Kirk Lund]

PS: the test is using DistributedRestoreSystemProperties as a JUnit Rule,
so it's saving and restoring all System properties before and after every
test. This gives each test a clean slate for System properties.


On Fri, Feb 3, 2017 at 1:41 PM, Kirk Lund  wrote:

> JMXMBeanDUnitTest has tests using SSL, not using SSL, configuring SSL with
> the old legacy config properties, configuring SSL with the new config
> properties.
>
> One test is currently marked as a FlakyTest: testJMXOverLegacySSL
>
> But it isn't a FlakyTest. By itself in fresh JVMs, testJMXOverLegacySSL
> passes 100% but if I run this test with the other tests
> in JMXMBeanDUnitTest it fails 100%. It always runs last (coincidence) and
> it apparently fails because a previous test has configured SSL in some way.
>
> I've tried adding "disconnectAllFromDS()" to tearDown but it still fails.
> I believe there's some static either in Geode code or JDK code that gets a
> value stuck in it from a previous test so that this test cannot pass.
>
> I tried adding "invokeInEveryVM(() -> SocketCreatorFactory.close());" to
> tearDown but it fails as well.
>
> I filed GEODE-2427 to better describe the problem since it's not really a
> Flaky test. JMXMBeanDUnitTest is an example of a test that we have marked
> as Flaky because when we run it via flakyTest, it gets fresh unused dunit
> JVMs. This really isn't the purpose of "FlakyTest" and this means we have
> some static somewhere that's getting stuck and I simply cannot find that
> static (or maybe it's a JDK bug or maybe it's something entirely different).
>
> Any idea what's preventing this test from passing. Below is the full stack
> of the failure when I run it with other tests:
>
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 10.118.33.232 with 4 VMs
>
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
> at org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(
> JMXMBeanDUnitTest.java:147)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(
> FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(
> ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(
> FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.
> evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(
> RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(
> BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.internal.runners.statements.RunBefores.
> evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
> JUnit4IdeaTestRunner.java:117)
> at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(
> JUnit4IdeaTestRunner.java:42)
> at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(
> JUnitStarter.java:262)
> at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> Caused by: java.io.IOException: Failed to retrieve RMIServer stub:
> javax.naming.CommunicationException [Root exception is
> java.rmi.ConnectIOException: error during JRMP connection 

[jira] [Commented] (GEODE-1435) Update LICENSE for native client bundled dependencies

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1435:


Commit 0347dfbf25110809c74094c6b8fa2942e450a629 in geode's branch 
refs/heads/next-gen-native-client-software-grant from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0347dfb ]

GEODE-1435: Correct licensing on ANTLR files.

- Add license for C++ parser.
- Remove verbose public domain statement for ANTLR.
- Remove Apache header from public domain files.


> Update LICENSE for native client bundled dependencies
> -
>
> Key: GEODE-1435
> URL: https://issues.apache.org/jira/browse/GEODE-1435
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Jacob S. Barrett
>
> We need to declare attribution for any bundled dependencies in the native 
> client source code.  If we choose to include the native client in the binary 
> distribution, we will need to declare those bundled libraries as well.
> See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Affected files:
> - LICENSE, NOTICE (source distribution)
> - geode-assembly/src/main/dist/LICENSE, NOTICE (binary distribution)
> Initial list of bundled source dependencies:
> - MersenneTwister (src/tests/cpp/fwklib/MersenneTwister.*pp)
> The binary dependencies can be reviewed in 
> geode-client-native/src/dependencies (some of these are not shipped though):
> - libxml2
> - xerces-c
> - openssl
> - ACE
> - antlr
> - sqlite
> - doxygen
> - gtest



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

[jira] [Commented] (GEODE-1435) Update LICENSE for native client bundled dependencies

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1435:


Commit 3860832ab39db5bdd858352df0f8bfd22b5dab87 in geode's branch 
refs/heads/next-gen-native-client-software-grant from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3860832 ]

GEODE-1435: Update license text

This closes #377


> Update LICENSE for native client bundled dependencies
> -
>
> Key: GEODE-1435
> URL: https://issues.apache.org/jira/browse/GEODE-1435
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Jacob S. Barrett
>
> We need to declare attribution for any bundled dependencies in the native 
> client source code.  If we choose to include the native client in the binary 
> distribution, we will need to declare those bundled libraries as well.
> See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Affected files:
> - LICENSE, NOTICE (source distribution)
> - geode-assembly/src/main/dist/LICENSE, NOTICE (binary distribution)
> Initial list of bundled source dependencies:
> - MersenneTwister (src/tests/cpp/fwklib/MersenneTwister.*pp)
> The binary dependencies can be reviewed in 
> geode-client-native/src/dependencies (some of these are not shipped though):
> - libxml2
> - xerces-c
> - openssl
> - ACE
> - antlr
> - sqlite
> - doxygen
> - gtest



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

[jira] [Commented] (GEODE-1435) Update LICENSE for native client bundled dependencies

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1435:


Commit 12ccffae8bbddf239c816e1097c3abe56107cad3 in geode's branch 
refs/heads/next-gen-native-client-software-grant from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=12ccffa ]

GEODE-1435: Adds binary distribution licensing.

* Adds binary licensing to binary package.
* Corrects error in source LICENSE file.


> Update LICENSE for native client bundled dependencies
> -
>
> Key: GEODE-1435
> URL: https://issues.apache.org/jira/browse/GEODE-1435
> Project: Geode
>  Issue Type: Sub-task
>  Components: native client
>Reporter: Anthony Baker
>Assignee: Jacob S. Barrett
>
> We need to declare attribution for any bundled dependencies in the native 
> client source code.  If we choose to include the native client in the binary 
> distribution, we will need to declare those bundled libraries as well.
> See 
> https://cwiki.apache.org/confluence/display/GEODE/License+Guide+for+Contributors.
> Affected files:
> - LICENSE, NOTICE (source distribution)
> - geode-assembly/src/main/dist/LICENSE, NOTICE (binary distribution)
> Initial list of bundled source dependencies:
> - MersenneTwister (src/tests/cpp/fwklib/MersenneTwister.*pp)
> The binary dependencies can be reviewed in 
> geode-client-native/src/dependencies (some of these are not shipped though):
> - libxml2
> - xerces-c
> - openssl
> - ACE
> - antlr
> - sqlite
> - doxygen
> - gtest



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

Re: Unable to build from 'develop' branch

[Kirk Lund]

[moved to dev]

The AsyncInvocation lambdas in MultiUserDUnitTest.testMultiUser do appear
to be ambiguous to me even if the later releases of JDK 1.8.0 no longer
detects it as ambiguous.

The 1st AsyncInvocation ends up invoking "public  AsyncInvocation
invokeAsync(final name, final SerializableCallableIF callable)" while
the later AsyncInvocation calls in that test end up invoking "public 
AsyncInvocation invokeAsync(final name, final SerializableRunnableIF
serializable)". The structure of the lambda blocks look identical to me (no
return and no unchecked exceptions).

That 1st call has no return value do differentiate it as a callable instead
of runnable, and in fact, if I insert a typecast to SerializableRunnableIF
it still compiles and runs fine but ends up invoking the
SerializableRunnableIF method instead of the SerializableCallableIF one:

Open MultiUserDUnitTest in IntelliJ or Eclipse, and follow the call to
invokeAsync, you'll see the following is interpreted as
*SerializableCallableIF*:

AsyncInvocation vm1Invoke = vm1.*invokeAsync*("run as data-reader", ()
-> {
  String shellId = getClass().getSimpleName() + "_vm1";
  HeadlessGfsh shell = new HeadlessGfsh(shellId, 30, gfshDir);
  while (true) {
connect((String) results[0], (Integer) results[1], (Integer)
results[2], shell,
"data-reader", "1234567");
Awaitility.waitAtMost(5, TimeUnit.MILLISECONDS);
shell.executeCommand("disconnect");
  }
});

Calls  "public  AsyncInvocation invokeAsync(final name, final
*SerializableCallableIF* callable)"

Next insert this typecast:

AsyncInvocation vm1Invoke = vm1.*invokeAsync*("run as data-reader",
*(SerializableRunnableIF)*() -> {
  String shellId = getClass().getSimpleName() + "_vm1";
  HeadlessGfsh shell = new HeadlessGfsh(shellId, 30, gfshDir);
  while (true) {
connect((String) results[0], (Integer) results[1], (Integer)
results[2], shell,
"data-reader", "1234567");
Awaitility.waitAtMost(5, TimeUnit.MILLISECONDS);
shell.executeCommand("disconnect");
  }
});

Now it calls  "public  AsyncInvocation invokeAsync(final name, final
*SerializableRunnableIF* serializable)"

A later version of 1.8.0 must have changed the inference rules slightly.

The later uses of AsyncInvocation in that same test look just as ambiguous
to me and yet they all call the SerializableRunnableIF flavor by default
instead of SerializableCallableIF.

The potential for the block of code to throw an unchecked Exception might
potentially cause a non-returning block to be interpreted as a Callable
instead of Serializable, but that's not happening in this case.

-Kirk

On Wed, Feb 1, 2017 at 9:07 AM, Dan Smith  wrote:

> Ah - I misread your JDK version. 1.8.0-b132 is *older* than 1.8.0_92-b14.
> Building with a newer JDK should fix the issue.
>
> -Dan
>
> On Wed, Feb 1, 2017 at 8:53 AM, Kevin Duling  wrote:
>
>> It's also building fine with :
>>
>> java version "1.8.0_92"
>>> Java(TM) SE Runtime Environment (build 1.8.0_92-b14)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.92-b14, mixed mode)
>>
>> I would suggest trying this, too:
>>
>> ./gradlew build -x spotlessCheck -x rat -x javadoc -x test
>>
>> I'm not sure -Dskip.tests=true works.
>>
>> On Wed, Feb 1, 2017 at 7:20 AM, Anthony Baker  wrote:
>>
>>> Seems to run clean on the latest Oracle JDK:
>>>
>>> ~/code/incubator-geode (develop)$ java -version
>>> java version "1.8.0_121"
>>> Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode)
>>>
>>> Anthony
>>>
>>>
>>> > On Jan 31, 2017, at 9:35 PM, Dan Smith  wrote:
>>> >
>>> > Hi Jags!
>>> >
>>> > Good to hear from you! I think it is related to the version of java 8
>>> that you are using. At least I know Anil hit that error with 1.8.0_20 and
>>> it went away by upgrading. See this earlier mail conversation -
>>> http://markmail.org/thread/srdhtpnelaa6axn4. But if have the latest JDK
>>> maybe this issue is back :(
>>> >
>>> > -Dan
>>> >
>>> > On Tue, Jan 31, 2017 at 8:44 PM, Anthony Baker 
>>> wrote:
>>> > Hi Jags!
>>> >
>>> > The master branch is the last release; the develop branch is the
>>> staging area for new work.  What JDK are you using?  What build command?
>>> >
>>> > I ran `gradle clean build` without trouble from the develop branch
>>> without seeing this error.
>>> >
>>> > Anthony
>>> >
>>> >
>>> >> On Jan 31, 2017, at 8:16 PM, Jags Ramnarayan <
>>> jramnara...@snappydata.io> wrote:
>>> >>
>>> >> Hi friends,
>>> >>  Trying to build from source but ran into this  I shouldn't
>>> be on the develop branch ?
>>> >>
>>> >> --
>>> >> /Users/jramnara/git/geode/geode-core/src/test/java/org/apach
>>> e/geode/management/internal/security/MultiUserDUnitTest.java:62: error:
>>> reference to invokeAsync is ambiguous
>>> >>
>>> >> 

[jira] [Updated] (GEODE-2427) JMXMBeanDUnitTest.testJMXOverLegacySSL cannot run with the other tests

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2427:
-
Description: 
JMXMBeanDUnitTest.testJMXOverLegacySSL is currently marked as a FlakyTest. If 
you run this test with the other tests in JMXMBeanDUnitTest it fails 100% of 
the time. By marking it as FlakyTest, it runs separately in its own JVMs during 
the FlakyTest task. This seems to be caused by the other tests setting some 
statics that don't get cleaned up before running testJMXOverLegacySSL. So 
there's some sort of product configuration pollution going on here.

JMXMBeanDUnitTest is cleaning up all System properties between tests, so the 
problem is not caused by a System property remaining set. It seems like it 
might have something to do with SSL configuration in JDK classes being static.

The FlakyTest task forks the testing JVMs for every test case so 
testJMXOverLegacySSL ends up with fresh JVMs under FlakyTest and it passes 100% 
that way.

{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host 
10.118.33.232 with 4 VMs

at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:280)
at 
org.apache.geode.management.JMXMBeanDUnitTest.testJMXOverLegacySSL(JMXMBeanDUnitTest.java:139)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
at 
com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
at 
com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
at 
com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.io.IOException: Failed to retrieve RMIServer stub: 
javax.naming.CommunicationException [Root exception is 
java.rmi.ConnectIOException: error during JRMP connection establishment; nested 
exception is: 
javax.net.ssl.SSLHandshakeException: 
sun.security.validator.ValidatorException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target]
at 
javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:369)
at 
javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
at 

[jira] [Commented] (GEODE-2409) Beautify readme file

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2409:


Commit 2ac69f9055a14939300b08c7814652a16ff26f5c in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=2ac69f9 ]

GEODE-2409: Beautify readme


> Beautify readme file
> 
>
> Key: GEODE-2409
> URL: https://issues.apache.org/jira/browse/GEODE-2409
> Project: Geode
>  Issue Type: Wish
>  Components: docs
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> The github readme is the first introduction many people have to Apache Geode. 
>  I think it could be made a bit prettier (e.g. by adding an Apache Geode 
> banner to the top of the readme and adding an Apache License button.)  There 
> is a great curated list of examples from which to draw inspiration available 
> at https://github.com/matiassingers/awesome-readme.  



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

[jira] [Commented] (GEODE-2410) afterPrimary and afterSecondary event listeners pass through the same critical section

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2410:


Commit d2a626e9cecb4d9a1b3599201a379eefe0dc8556 in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=d2a626e ]

GEODE-2410: Lucene afterPrimary and afterSecondary calls pass through the same 
crit section.

* afterPrimary and afterSecondary calls are passed through the same 
critical section.
* If the caller is primary bucket, it will try to acquire a Dlock on 
the bucket and create the index repo.
* If it is secondary it will clean up the repo - close the writer and 
release the locks.
* If the primary changes to secondary while waiting for indexes to be 
created, it will exit from the critical section without acquiring the lock.


> afterPrimary and afterSecondary event listeners pass through the same 
> critical section
> --
>
> Key: GEODE-2410
> URL: https://issues.apache.org/jira/browse/GEODE-2410
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: nabarun
> Fix For: 1.1.0
>
>
> * afterPrimary and afterSecondary listeners will call the same critical 
> section.
> * They will acquire a Dlock on the bucket and create the index if primary.
> * If they are secondary it will close the writer and release the Dlock.
> * The primary will reattempt to acquire the lock after 5seconds and continue 
> to loop as long as it is still primary.



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

[jira] [Commented] (GEODE-2227) AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError on Windows

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2227:


Commit 7b5e2ccd7f0ab2f2c716d7252dd006ecd1b55b53 in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~vectorijk]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=7b5e2cc ]

GEODE-2227 AutoSerializableJUnitTest.testMultipleClassLoaders fails on Windows

This closes #330


> AutoSerializableJUnitTest.testMultipleClassLoaders fails with AssertionError 
> on Windows
> ---
>
> Key: GEODE-2227
> URL: https://issues.apache.org/jira/browse/GEODE-2227
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.0.0-incubating
> Environment: Windows
>Reporter: Kirk Lund
>Assignee: Kai Jiang
>  Labels: IntegrationTest, Windows
> Fix For: 1.2.0
>
>
> {noformat}
> java.lang.AssertionError
>   at org.junit.Assert.fail(Assert.java:86)
>   at org.junit.Assert.assertTrue(Assert.java:41)
>   at org.junit.Assert.assertFalse(Assert.java:64)
>   at org.junit.Assert.assertFalse(Assert.java:74)
>   at 
> org.apache.geode.pdx.AutoSerializableJUnitTest.testMultipleClassLoaders(AutoSerializableJUnitTest.java:1275)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> 

[jira] [Commented] (GEODE-2269) It seems the gfsh "remove" command cannot remove r...

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2269:


Commit c1bedbce87a0ca09b333afd1590f5d1bdd9e463c in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~ggreen]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c1bedbc ]

GEODE-2269 Allow region entries with non null empty key such as zero length 
strings to be removed

This closes #353


> It seems the gfsh "remove" command cannot remove r...
> -
>
> Key: GEODE-2269
> URL: https://issues.apache.org/jira/browse/GEODE-2269
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Gregory Green
> Fix For: 1.2.0
>
>
> It seems the gfsh "remove" command cannot remove region entries with a 0 
> length string key.
> gfsh>query --query="select toString().length() from /Recipient.keySet()"
> Result : true
> startCount : 0
> endCount   : 20
> Rows   : 3
> Result
> --
> 0
> 2
> 5
> gfsh>remove --region=/Recipient --key=""
> Message : Key is either empty or Null
> Result  : false
> gfsh>remove --region=/Recipient --key="''"
> Message : Key is either empty or Null
> Result  : false



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

[jira] [Commented] (GEODE-2414) Determine a mechanism to stream a zip file from server to locator

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2414:


Commit c6fa2b9ebc86e1de3535fab6745814ea54ebd30d in geode's branch 
refs/heads/feature/GEODE-1930-2 from [~gosullivan]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c6fa2b9 ]

GEODE-2414: mark a failing test as flaky. This closes #382

This is just a temporary fix for CI until we can diagnose the issue.


> Determine a mechanism to stream a zip file from server to locator
> -
>
> Key: GEODE-2414
> URL: https://issues.apache.org/jira/browse/GEODE-2414
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, gfsh
>Reporter: Jared Stewart
>
> Our export command will execute a function on servers (one at a time) to 
> build up a zip file of the artifacts for that server.  Then, the zip file 
> needs to be sent back to the locator, so that the locator can aggregate 
> together the files from all servers.  However, we need to make sure to 
> chunk/stream the data that we send from server to locator so that neither 
> member will run out of memory if the file is very large.



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

[jira] [Commented] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2386:


Commit 3a12d61197877b55b882ebb69caf760b699c785b in geode's branch 
refs/heads/develop from [~upthewaterspout]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3a12d61 ]

GEODE-2386 Don't call System.setProperties(null) when rule is used twice

Fixing DistributedRestoreSystemProperties rule so that if the rule is
included twice within a test, it does not end up calling
System.setProperties(null). That will prevent us from losing the value
of java.class.path set by gradle.

Reverting the workaround that didn't actually work.


> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
> Fix For: 1.2.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> 

[jira] [Updated] (GEODE-2426) Build dotNetty on Windows

[Michael Martell (JIRA)]

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

Michael Martell updated GEODE-2426:
---
Description: 
Download latest version and build. 

Then download/build/run a test sample.

> Build dotNetty on Windows
> -
>
> Key: GEODE-2426
> URL: https://issues.apache.org/jira/browse/GEODE-2426
> Project: Geode
>  Issue Type: Task
>  Components: native client
>Reporter: Michael Martell
>
> Download latest version and build. 
> Then download/build/run a test sample.



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

[jira] [Updated] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2386:
---
Fix Version/s: (was: 1.1.0)
   1.2.0

> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
> Fix For: 1.2.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: VMs did not start up within 120 seconds
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launch(DUnitLauncher.java:220)
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:142)
>   ... 34 more
> Standard Output
> Executing [/usr/local/asfpackages/java/jdk1.8.0_102/jre/bin/java, -classpath, 
> 

[jira] [Commented] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra commented on GEODE-2386:


[~upthewaterspout] Just out of curiosity, sounds like its test issue then why 
we unable to reproduce it locally. i am moving this out of 1.1.0. Please update 
it accordingly.

> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
> Fix For: 1.2.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: VMs did not start up within 120 seconds
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launch(DUnitLauncher.java:220)
>   at 
> 

[jira] [Updated] (GEODE-2386) Unable to launch dunit VMs in nightly builds

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra updated GEODE-2386:
---
Component/s: (was: build)
 lucene

> Unable to launch dunit VMs in nightly builds
> 
>
> Key: GEODE-2386
> URL: https://issues.apache.org/jira/browse/GEODE-2386
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Dan Smith
> Fix For: 1.1.0
>
> Attachments: reproduce.patch
>
>
> The recent apache nightly builds for the release branch and develop are 
> seeing lucene tests fail with "java.lang.RuntimeException: Unable to launch 
> dunit VMs". In the logs we see this error message:
> "[locator] Error: Could not find or load main class 
> org.apache.geode.test.dunit.standalone.ChildVM"
> We need to figure out what's going on.
> https://builds.apache.org/job/Geode-release/40/#showFailuresLink
> https://builds.apache.org/job/Geode-nightly/731/
> {noformat}
> Stacktrace
> java.lang.RuntimeException: Unable to launch dunit VMs
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:144)
>   at 
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:131)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
>   at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
>   at 
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
>   at sun.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.RuntimeException: VMs did not start up within 120 seconds
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launch(DUnitLauncher.java:220)
>   at 
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:142)
>   ... 34 more
> Standard Output
> Executing [/usr/local/asfpackages/java/jdk1.8.0_102/jre/bin/java, -classpath, 
> 

[jira] [Assigned] (GEODE-2413) peer-to-peer authentication: Peer need to re-authenticate coordinator while accepting view message

[Hitesh Khamesra (JIRA)]

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

Hitesh Khamesra reassigned GEODE-2413:
--

Assignee: Hitesh Khamesra

> peer-to-peer authentication: Peer need to re-authenticate coordinator while 
> accepting view message
> --
>
> Key: GEODE-2413
> URL: https://issues.apache.org/jira/browse/GEODE-2413
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Hitesh Khamesra
>Assignee: Hitesh Khamesra
> Fix For: 1.1.0
>
>
> In peer-to-peer authentication, coordinator authenticates the joining member. 
> Then coordinator includes that new member in the cluster and sends new view 
> message. This view message should include coordinator's credential so that 
> joining member can authenticate coordinator as well (i.e. mutual 
> authentication)



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

[jira] [Commented] (GEODE-2206) Add junit-quickcheck to Gradle test dependencies.

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/383#discussion_r99371844
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerQuickcheckStringTest.java
 ---
@@ -0,0 +1,63 @@
+/*
+ * 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;
+
+import static org.junit.Assert.*;
+
+import com.pholser.junit.quickcheck.Property;
+import com.pholser.junit.quickcheck.runner.JUnitQuickcheck;
+import org.apache.geode.DataSerializer;
+import org.apache.geode.test.junit.categories.UnitTest;
+import org.junit.Before;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+
+import java.io.ByteArrayOutputStream;
+import java.io.ByteArrayInputStream;
+import java.io.DataInputStream;
+import java.io.DataOutputStream;
+import java.io.IOException;
+
+/**
+ * Tests the serialization and deserialization of randomly generated 
Strings.
+ *
+ * The current implementation (0.7 or 0.8alpha2) of 
junit-quickcheck-generators only generates valid
+ * codepoints, and that it doesn't tend to test strings that are 
particularly long, though the more
+ * trials you run, the longer they get.
+ */
+@Category(UnitTest.class)
+@RunWith(JUnitQuickcheck.class)
+public class InternalDataSerializerQuickcheckStringTest {
+  @Property(trials = 1000)
+  public void StringSerializedDeserializesToSameValue(String 
originalString) throws IOException {
+ByteArrayOutputStream byteArrayOutputStream = new 
ByteArrayOutputStream();
+DataOutputStream dataOutputStream = new 
DataOutputStream(byteArrayOutputStream);
+
+DataSerializer.writeString(originalString, dataOutputStream);
+dataOutputStream.flush();
+
+byte[] stringBytes = byteArrayOutputStream.toByteArray();
+DataInputStream dataInputStream = new DataInputStream(new 
ByteArrayInputStream(stringBytes));
+String returnedString = DataSerializer.readString(dataInputStream);
+
+assertEquals("Deserialized string matches original", originalString, 
returnedString);
--- End diff --

Yeah, I'm not sure why IntelliJ doesn't show the seed. I remember there 
being a way to run int tests on *all* inputs. I don't see it in the docs now, 
but you could write your own generator and run with that to do exhaustive 
testing of something that you knew failed.


> Add junit-quickcheck to Gradle test dependencies.
> -
>
> Key: GEODE-2206
> URL: https://issues.apache.org/jira/browse/GEODE-2206
> Project: Geode
>  Issue Type: Improvement
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>
> Unit tests allow us to test cases we know about and have thought of. 
> Property-based testing allows us to test those, and some cases we haven't 
> thought of -- you're essentially fuzzing a limited subset of the code. 
> {{junit-quickcheck}} makes it easy to write "property-based" tests with 
> generators for the builtin types. You can also constrain input or build 
> custom generators for constrained data.
> I think this would be especially helpful for testing areas like PDX 
> serialization, which should be able to accept any serializable object a user 
> creates.



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

[GitHub] geode pull request #383: GEODE-2206: Add junit-quickcheck to geode-core.

[galen-pivotal]

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

https://github.com/apache/geode/pull/383#discussion_r99371844
  
--- Diff: 
geode-core/src/test/java/org/apache/geode/internal/InternalDataSerializerQuickcheckStringTest.java
 ---
@@ -0,0 +1,63 @@
+/*
+ * 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;
+
+import static org.junit.Assert.*;
+
+import com.pholser.junit.quickcheck.Property;
+import com.pholser.junit.quickcheck.runner.JUnitQuickcheck;
+import org.apache.geode.DataSerializer;
+import org.apache.geode.test.junit.categories.UnitTest;
+import org.junit.Before;
+import org.junit.experimental.categories.Category;
+import org.junit.runner.RunWith;
+
+import java.io.ByteArrayOutputStream;
+import java.io.ByteArrayInputStream;
+import java.io.DataInputStream;
+import java.io.DataOutputStream;
+import java.io.IOException;
+
+/**
+ * Tests the serialization and deserialization of randomly generated 
Strings.
+ *
+ * The current implementation (0.7 or 0.8alpha2) of 
junit-quickcheck-generators only generates valid
+ * codepoints, and that it doesn't tend to test strings that are 
particularly long, though the more
+ * trials you run, the longer they get.
+ */
+@Category(UnitTest.class)
+@RunWith(JUnitQuickcheck.class)
+public class InternalDataSerializerQuickcheckStringTest {
+  @Property(trials = 1000)
+  public void StringSerializedDeserializesToSameValue(String 
originalString) throws IOException {
+ByteArrayOutputStream byteArrayOutputStream = new 
ByteArrayOutputStream();
+DataOutputStream dataOutputStream = new 
DataOutputStream(byteArrayOutputStream);
+
+DataSerializer.writeString(originalString, dataOutputStream);
+dataOutputStream.flush();
+
+byte[] stringBytes = byteArrayOutputStream.toByteArray();
+DataInputStream dataInputStream = new DataInputStream(new 
ByteArrayInputStream(stringBytes));
+String returnedString = DataSerializer.readString(dataInputStream);
+
+assertEquals("Deserialized string matches original", originalString, 
returnedString);
--- End diff --

Yeah, I'm not sure why IntelliJ doesn't show the seed. I remember there 
being a way to run int tests on *all* inputs. I don't see it in the docs now, 
but you could write your own generator and run with that to do exhaustive 
testing of something that you knew failed.


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

Build failed in Jenkins: Geode-nightly #736

[Apache Jenkins Server]

See 

Changes:

[hiteshk25] GEODE-2414: mark a failing test as flaky. This closes #382

[nnag] GEODE-2372: handleException prints the stacktrace when debug enabled

[nnag] GEODE-2410: Lucene afterPrimary and afterSecondary calls pass through

[upthewaterspout] GEODE-2269 Allow region entries with non null empty key such 
as zero

[abaker] GEODE-2227 AutoSerializableJUnitTest.testMultipleClassLoaders fails on

[abaker] GEODE-2172 CustomConfigWithCacheIntegrationTest fails on Windows

[abaker] GEODE-2409: Beautify readme

--
[...truncated 549 lines...]
at 
com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
at 
org.apache.geode.distributed.LocatorDUnitTest.lambda$testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator$bb17a952$1(LocatorDUnitTest.java:536)

org.apache.geode.distributed.LocatorUDPSecurityDUnitTest > 
testSSLEnabledLocatorDiesWhenConnectingToNonSSLLocator FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.distributed.LocatorDUnitTest$$Lambda$17/2068181318.run in VM 2 
running on Host asf920.gq1.ygridcore.net with 4 VMs

Caused by:
com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
alias 'locator2 dies' didn't complete within 30 seconds because condition with 
org.apache.geode.distributed.LocatorDUnitTest was not fulfilled.

268 tests completed, 2 failed, 6 skipped
:geode-core:flakyTest FAILED
: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:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
: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:flakyTest 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:flakyTest
: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:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
: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:flakyTest
: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
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:flakyTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

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

[GitHub] geode issue #326: Feature/geode 2103 : Adding --http-service-port and --http...

[deepakddixit]

Github user deepakddixit commented on the issue:

https://github.com/apache/geode/pull/326
  
@metatype I have updated the golden-help-offline.properties. The 
integration test HelpCommandsIntegrationTest is generic one checking the help 
 and confirms the contents from golden-help-offline.properties. It is 
passing with changes made in golden-help-offline.properties


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