[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


Commit 8ddafe94ee758750206b1083d7a01f722cf93dea in geode-native's branch 
refs/heads/develop from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=8ddafe9 ]

GEODE-2513 Unbrand docs section on Preserving Data

- Remove references to GemFire
- Fix typos
- Clarify links that leave the native-manual


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

Re: [GSoC] Interested in GSoC 2017 ideas

[Kai Jiang]

Hi Hitesh,

Thanks! I pretty like your ideas. Could I discuss more about the details of
your ideas offline?
I would like to write the proposal right away since the application of GSoC
will start very soon (Mar 20th).

Looking forward!

Best,
Kai

On Wed, Mar 8, 2017 at 6:14 PM, Hitesh Khamesra  wrote:

> Hi Kai:
>
> I have couple of ideas..
>
> 1. Reliable event processing on Geode.
> 2. New developer friendly apis on Geode.
>
> Let me know if you some query on this or you have some other idea.
>
> Thanks.
> Hitesh
>
>
> --
> *From:* Kai Jiang 
> *To:* dev@geode.apache.org
> *Cc:* William Markito Oliveira ; Hitesh
> Khamesra 
> *Sent:* Tuesday, March 7, 2017 8:05 AM
> *Subject:* Re: [GSoC] Interested in GSoC 2017 ideas
>
> @Anthony,
> Thanks! I really appreciate for your help and information!
>
> @Hitesh,
> Nice to e-meet you here! Do you have any idea about GSoC project with
> Geode this year?
> Looking forward!
>
> Best,
> Kai
>
> On Tue, Mar 7, 2017 at 7:02 AM, Anthony Baker  wrote:
>
> Hi Kai,
>
> Welcome, and thanks for your interest!  We have one committer interested
> in mentoring so far (Hitesh Khamesra  hitesh...@yahoo.com>>) .  Please feel free to reach out to the community
> for help or questions.  Best of luck to you!
>
> @Committers:  if you want to participate as a mentor in GSoC, now is the
> time to get involved.
>
> Anthony
>
> > On Mar 6, 2017, at 7:30 AM, Kai Jiang  wrote:
> >
> > Hi All,
> >
> > I am Kai, a master student majoring in CS from Portland State University,
> > highly interested in Big data and Distributed System. I have contributed
> to
> > Apache Spark as a GSoC project last year.
> >
> > I've been contributing to Geode codebase. Some my Pull Requests are
> here.(
> > https://github.com/apache/geod e/pulls?q=is%3Apr+author%3Avec
> torijk+is%3Aclosed
> 
> > )
> > Also, I did some experiments on last year GSoC idea (GEODE-194
> >  > Geode Spark Connector
> > does not support Spark 2.0) on my branch (
> > https://github.com/vectorijk/g eode/commits/spark2
> ). I would like to
> extend
> > my work with Geode as a GSoC project this year and look forward to
> writing
> > something meaningful and impactful.
> >
> > Is there any Geode Committer who's going to sign up as a mentor for GSoC
> > this year? Maybe you could tell me about the projects you are going to
> > mentor and give me some suggestions about what issues I could fix now to
> > get involved. If community has anything else in mind, I am very willing
> to
> > work on some issues before GSoC and get started with something new during
> > GSoC.
> >
> > Looking forward!
> >
> > Best,
> > Kai Jiang
> > github.com/vectorijk
>
>
>
>
>

Build failed in Jenkins: Geode-nightly #775

[Apache Jenkins Server]

See 

--
[...truncated 99.58 KB...]
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)

Caused by:
java.lang.NullPointerException
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.put(ClientHealthStatsDUnitTest.java:369)
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.lambda$testClientHealthStats_SubscriptionEnabled$bb17a952$2(ClientHealthStatsDUnitTest.java:128)

6834 tests completed, 1 failed, 606 skipped
:geode-core:distributedTest FAILED
:geode-core:flakyTest
: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
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json: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: 

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

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

[jira] [Comment Edited] (GEODE-2544) gfsh incorrectly reports that tools.jar is required if JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar edited comment on GEODE-2544 at 3/13/17 4:41 PM:
--

Since the attach API is disabled by default, this is no longer needed.


was (Author: swapnil.bawaskar):
Sicne the attach API is disabled by default, this is no longer needed.

> gfsh incorrectly reports that tools.jar is required if 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> --
>
> Key: GEODE-2544
> URL: https://issues.apache.org/jira/browse/GEODE-2544
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This behavior is incorrect. The ProcessControllerFactory should use 
> FileProcessUtils instead of AttachProcessUtils without any error or warning.
> {noformat}
> /home/klund/latvia/dev/geode [1042]$ export 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> /home/klund/latvia/dev/geode [1044]$ 
> ./geode-assembly/build/install/apache-geode/bin/gfsh
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /export/latvia1/users/klund/dev/geode/loc1...
> An error occurred while attempting to start a Locator in 
> /export/latvia1/users/klund/dev/geode/loc1 on latvia.gemstone.com[10334]: The 
> Attach API classes could not be found on the classpath.  Please include JDK 
> tools.jar on the classpath or add the JDK tools.jar to the jre/lib/ext 
> directory.
> {noformat}



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

[jira] [Resolved] (GEODE-2544) gfsh incorrectly reports that tools.jar is required if JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar resolved GEODE-2544.
-
Resolution: Won't Fix

> gfsh incorrectly reports that tools.jar is required if 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> --
>
> Key: GEODE-2544
> URL: https://issues.apache.org/jira/browse/GEODE-2544
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This behavior is incorrect. The ProcessControllerFactory should use 
> FileProcessUtils instead of AttachProcessUtils without any error or warning.
> {noformat}
> /home/klund/latvia/dev/geode [1042]$ export 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> /home/klund/latvia/dev/geode [1044]$ 
> ./geode-assembly/build/install/apache-geode/bin/gfsh
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /export/latvia1/users/klund/dev/geode/loc1...
> An error occurred while attempting to start a Locator in 
> /export/latvia1/users/klund/dev/geode/loc1 on latvia.gemstone.com[10334]: The 
> Attach API classes could not be found on the classpath.  Please include JDK 
> tools.jar on the classpath or add the JDK tools.jar to the jre/lib/ext 
> directory.
> {noformat}



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

[jira] [Commented] (GEODE-2544) gfsh incorrectly reports that tools.jar is required if JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar commented on GEODE-2544:
-

Sicne the attach API is disabled by default, this is no longer needed.

> gfsh incorrectly reports that tools.jar is required if 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> --
>
> Key: GEODE-2544
> URL: https://issues.apache.org/jira/browse/GEODE-2544
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This behavior is incorrect. The ProcessControllerFactory should use 
> FileProcessUtils instead of AttachProcessUtils without any error or warning.
> {noformat}
> /home/klund/latvia/dev/geode [1042]$ export 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> /home/klund/latvia/dev/geode [1044]$ 
> ./geode-assembly/build/install/apache-geode/bin/gfsh
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /export/latvia1/users/klund/dev/geode/loc1...
> An error occurred while attempting to start a Locator in 
> /export/latvia1/users/klund/dev/geode/loc1 on latvia.gemstone.com[10334]: The 
> Attach API classes could not be found on the classpath.  Please include JDK 
> tools.jar on the classpath or add the JDK tools.jar to the jre/lib/ext 
> directory.
> {noformat}



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

[jira] [Closed] (GEODE-2544) gfsh incorrectly reports that tools.jar is required if JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true

[Swapnil Bawaskar (JIRA)]

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

Swapnil Bawaskar closed GEODE-2544.
---

> gfsh incorrectly reports that tools.jar is required if 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> --
>
> Key: GEODE-2544
> URL: https://issues.apache.org/jira/browse/GEODE-2544
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> This behavior is incorrect. The ProcessControllerFactory should use 
> FileProcessUtils instead of AttachProcessUtils without any error or warning.
> {noformat}
> /home/klund/latvia/dev/geode [1042]$ export 
> JAVA_ARGS=-Dgemfire.test.ProcessControllerFactory.DisableAttachApi=true
> /home/klund/latvia/dev/geode [1044]$ 
> ./geode-assembly/build/install/apache-geode/bin/gfsh
> gfsh>start locator --name=loc1
> Starting a Geode Locator in /export/latvia1/users/klund/dev/geode/loc1...
> An error occurred while attempting to start a Locator in 
> /export/latvia1/users/klund/dev/geode/loc1 on latvia.gemstone.com[10334]: The 
> Attach API classes could not be found on the classpath.  Please include JDK 
> tools.jar on the classpath or add the JDK tools.jar to the jre/lib/ext 
> directory.
> {noformat}



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

[GitHub] geode pull request #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOne...

[bschuchardt]

Github user bschuchardt closed the pull request at:

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


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

[GitHub] geode issue #412: GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSL...

[bschuchardt]

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/412
  
remote: geode git commit: GEODE_1793 spotless fixes and removal of dead code
remote: geode git commit: GEODE-1793 
LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
To https://git-wip-us.apache.org/repos/asf/geode.git
   c09a856..4112204  develop -> develop



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

[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt commented on the issue:

https://github.com/apache/geode/pull/412
  
remote: geode git commit: GEODE_1793 spotless fixes and removal of dead code
remote: geode git commit: GEODE-1793 
LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
To https://git-wip-us.apache.org/repos/asf/geode.git
   c09a856..4112204  develop -> develop



> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> ---
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined 
> what the problem is, but it will run perfectly by itself everytime, but once 
> run inside of the TestClass it fails



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

[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

[ASF GitHub Bot (JIRA)]

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

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

Github user bschuchardt closed the pull request at:

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


> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> ---
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined 
> what the problem is, but it will run perfectly by itself everytime, but once 
> run inside of the TestClass it fails



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

[jira] [Commented] (GEODE-2542) LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode Nightly Build

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2542:


Commit 064362e90e150ad4ef5b269fab78f0cf2d6e5f4f in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=064362e ]

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.


> LocatorDUnitTest and LocatorUDPSecurityDUnitTest fail frequently in Geode 
> Nightly Build
> ---
>
> Key: GEODE-2542
> URL: https://issues.apache.org/jira/browse/GEODE-2542
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Kirk Lund
>  Labels: Flaky
>
> testMultipleLocators:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host 
> asf919.gq1.ygridcore.net with 5 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.distributed.LocatorDUnitTest.testMultipleLocators(LocatorDUnitTest.java:1567)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.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: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$DispatchingInvocat

[jira] [Commented] (GEODE-1793) Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1793:


Commit 064362e90e150ad4ef5b269fab78f0cf2d6e5f4f in geode's branch 
refs/heads/develop from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=064362e ]

GEODE-1793 LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL

This was a product issue.  When the locator using plain-text sockets is
contacted by a TcpClient using SSL the locator often just closes the socket.
On some platforms this causes a SSLHandshakeException but on others it
just causes a "SocketException: connection reset".  Writing some text to
the socket forces the TcpClient to get a SSLException (which is the superclass
of SSLHandshakeException).

The test class is still marked as Flaky due to GEODE-2542.


> Flaky: LocatorDUnitTest.testStartTwoLocatorsOneWithSSLAndTheOtherNonSSL
> ---
>
> Key: GEODE-1793
> URL: https://issues.apache.org/jira/browse/GEODE-1793
> Project: Geode
>  Issue Type: Bug
>  Components: locator
>Reporter: Udo Kohlmeyer
>Assignee: Galen O'Sullivan
>Priority: Minor
>
> This test fails due to something not cleaning itself properly. Undetermined 
> what the problem is, but it will run perfectly by itself everytime, but once 
> run inside of the TestClass it fails



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

[jira] [Commented] (GEODE-2612) Add option to invoke callbacks while loading a snapshot

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2612:


Commit f111cfef8d192b97b35a2433a31bb58fd772f2d0 in geode's branch 
refs/heads/develop from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f111cfe ]

GEODE-2612: Added gfsh support for invoking callbacks during snapshot load


> Add option to invoke callbacks while loading a snapshot
> ---
>
> Key: GEODE-2612
> URL: https://issues.apache.org/jira/browse/GEODE-2612
> Project: Geode
>  Issue Type: New Feature
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> As a work-around to recreating a lucene index (which is not currently 
> supported), the recommendation is to:
> - export user region
> - destroy indexes and user region
> - recreate index
> - recreate user region
> - import user region
> The lucene index is populated using an hidden AsyncEventQueue, but currently 
> import doesn't invoke callbacks. This feature request is to add an option to 
> SnapshotOptions to cause callbacks to be invoked, so that the index is 
> repopulated during import.



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

Re: Review Request 57514: GEODE-2267: enhance error output for gfsh.

[Jinmei Liao]

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

(Updated March 13, 2017, 5:32 p.m.)


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


Repository: geode


Description
---

* correctly output error message if gfsh execution has an error
* export logs should output correct log message over http connection as well


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
 36d071c153ed8c2559cc8c29e248058b42cbf7ff 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 0351573f6eda80e1751bd6b95efdbe6ce36a620d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
 b7f8c2a080614ab59dc9da29c31f606749b58e4a 
  
geode-core/src/test/java/org/apache/geode/management/internal/web/controllers/ExportLogControllerTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 f3674581d6e27bba8932294152cc2db8727a4024 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
 cc4ae28ff97fc50c3a9298ea3355847008776ec3 
  
geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpIntegrationTest.java
 PRE-CREATION 


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

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


Testing
---

precheckin running ...


Thanks,

Jinmei Liao

[jira] [Assigned] (GEODE-2645) Refactor CacheLogRollDUnitTest to be an IntegrationTest

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2645:


Assignee: Kirk Lund

> Refactor CacheLogRollDUnitTest to be an IntegrationTest
> ---
>
> Key: GEODE-2645
> URL: https://issues.apache.org/jira/browse/GEODE-2645
> Project: Geode
>  Issue Type: Wish
>  Components: logging, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> CacheLogRollDUnitTest appears to only use one JVM so it should be ported from 
> using DUnit to being a more simple IntegrationTest.
> It also has 4 flaky test bugs:
> * GEODE-674
> * GEODE-675
> * GEODE-676
> * GEODE-677
> If possible, test cleanup should also try to resolve the flakiness in these 
> tests.



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

[jira] [Resolved] (GEODE-2313) PulseDataExportTest.dataBrowserExportWorksAsExpected fails with ConditionTimeoutException

[Kirk Lund (JIRA)]

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

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

> PulseDataExportTest.dataBrowserExportWorksAsExpected fails with 
> ConditionTimeoutException
> -
>
> Key: GEODE-2313
> URL: https://issues.apache.org/jira/browse/GEODE-2313
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
> Fix For: 1.2.0
>
>
> {noformat}
> org.apache.geode.tools.pulse.tests.PulseDataExportTest > 
> dataBrowserExportWorksAsExpected FAILED
> com.jayway.awaitility.core.ConditionTimeoutException: Condition with 
> lambda expression in org.apache.geode.tools.pulse.tests.PulseDataExportTest 
> was not fulfilled within 2 minutes.
> at 
> com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79)
> at 
> com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764)
> at 
> com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741)
> at 
> org.apache.geode.tools.pulse.tests.PulseDataExportTest.before(PulseDataExportTest.java:99)
> {noformat}



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

[jira] [Commented] (GEODE-2621) CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2621:


Commit fe339587bfccbcb264067d2abbc42f85ebda6e5d in geode's branch 
refs/heads/GEODE-2290 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=fe33958 ]

GEODE-2621: Reduce time sensitivity of ExportLogsDUnitTest


> CI Failure: ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering
> --
>
> Key: GEODE-2621
> URL: https://issues.apache.org/jira/browse/GEODE-2621
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Affects Versions: 1.1.0
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Minor
>  Labels: CI, Flaky
>
> {code}
> See 
> 
> Changes:
> [jiliao] GEODE-2267: mark local time sensitive tests as flaky
> [khowe] GEODE-2488: Remove test from flaky category
> [nnag] GEODE-2596: Lucene metrics moved to public API
> [nnag] GEODE-2604: Added javadoc comments to LuceneIndexMetrics.java
> [nnag] GEODE-2604: Added measurement units to the javadoc comments
> --
> [...truncated 99.83 KB...]
> :geode-core:flakyTest
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
>java.lang.AssertionError: 
>Expected size:<3> but was:<1> in:
><[/tmp/junit3849272601382305906/unzippedLogs/server-2]>
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:227)
>at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:157)
> {code}



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

[jira] [Commented] (GEODE-1198) CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1198:


Commit 168f4cebc43d69859b976580f422abd0128770c2 in geode's branch 
refs/heads/GEODE-2290 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=168f4ce ]

GEODE-1198: add todo comment to dubious test


> CI Failure: DistributedSystemDUnitTest.testConflictingUDPPort
> -
>
> Key: GEODE-1198
> URL: https://issues.apache.org/jira/browse/GEODE-1198
> Project: Geode
>  Issue Type: Bug
>  Components: membership, tests
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: Flaky
> Fix For: 1.2.0
>
>
> Geode_develop_DistributedTests/2178/
> Revision: 7413804dec6acc1077618d50459e07200ced8336
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest$2.run in VM 1 
> running on Host rooktwo.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:439)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:381)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:317)
>   at 
> com.gemstone.gemfire.distributed.DistributedSystemDUnitTest.testConflictingUDPPort(DistributedSystemDUnitTest.java:380)
>   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.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
>   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.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
>   at 
> org.gradle.messaging.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:106)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImp

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


Commit 3bde1a748c4e1dbb4580032e8144cd6fa697d85d in geode's branch 
refs/heads/GEODE-2290 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=3bde1a7 ]

GEODE-2539: Upgrading Jetty causes RestSecurityItegrationTest to fail


> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.Redire

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


Commit 0ca3fe271bc4e30a352f5a9b600b5a58bb2c4a92 in geode's branch 
refs/heads/GEODE-2290 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=0ca3fe2 ]

GEODE-2614: fix javadoc warnings


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Commented] (GEODE-2614) Build generates javadoc warnings

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2614:


Commit 886c8080b1383c9e388dd9aa2197c17bd095e758 in geode's branch 
refs/heads/GEODE-2290 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=886c808 ]

GEODE-2614: fix javadoc warnings - spotless


> Build generates javadoc warnings
> 
>
> Key: GEODE-2614
> URL: https://issues.apache.org/jira/browse/GEODE-2614
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, jmx
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>  Labels: javadocs
> Fix For: 1.2.0
>
>
> {noformat}
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "logFilter:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseLogFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java:56:
>  warning - @param argument "baseStatsFile:" is not a parameter name.
> /Users/klund/dev/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/CliAroundInterceptor.java:45:
>  warning - @param argument "tempFile:" is not a parameter name.
> {noformat}



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

[jira] [Commented] (GEODE-2290) Provide way to limit scanning of deployed jars

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2290:


Commit 5934e7e39751dba9f591900b35e49a880adb3cae in geode's branch 
refs/heads/GEODE-2290 from [~jstewart]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=5934e7e ]

GEODE-2290: Remove JarClassLoader

Cherry pick test from lazy loading branch

Enhance DeployCommandRedeployDUnitTest

Fixed backup of user jars

Fixed deploy tests

Fixed undeploy test


> Provide way to limit scanning of deployed jars
> --
>
> Key: GEODE-2290
> URL: https://issues.apache.org/jira/browse/GEODE-2290
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, management
>Reporter: Kirk Lund
>  Labels: ClassLoader, DeployCommand, deploy, gfsh
>
> Currently if you use the GFSH command "deploy jar" the deployed jar will be 
> scanned in such a way that the deployer will load and resolve every .class 
> file in the jar file. The original intention of "deploy jar" was that only 
> Functions would be deployed. Any .class that is found to be a Function is 
> automatically registered with the FunctionService. 
> You can also include implementations of other Apache Geode callbacks such as 
> CacheListener. If you then follow up the deploy with "alter region" you can 
> alter the region to add the CacheListener or other callback.
> Some users have reported trying to deploy a jar with much more than just 
> Functions or CacheListeners or domain classes used for Region Entries. If the 
> jar includes a class that the callbacks or domain classes don't directly use 
> but that class requires a missing transitive dependency, then the deployer 
> will generate a NoClassDefFoundError when it tries to load and resolve that 
> class.
> Along with the potential NoClassDefFoundError, forcing every .class to be 
> loaded and resolved can consume a lot of PermGen memory.
> Various ideas have been tossed around to allow someone to deploy such a jar 
> without having the deployer generate NoClassDefFoundError. This requires 
> something like one of the following approaches:
> 1) add a new --do-not-deploy option flag
> 2) comma-delimited list of classes to load and deploy
> 3) regex list of classes to load and deploy
> 4) have I missed something?
> This would give the User better control over which classes to actually load 
> and resolve.
> [NOTE: I'll update this ticket based on feedback and discussion on 
> dev@geode.apache.org]



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

[jira] [Commented] (GEODE-2553) After deleting and recreating my Lucene index and region, my Lucene query hung.

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2553:


Commit 38cf13ffbbc912f78bdacb1caf835508abe1b5e3 in geode's branch 
refs/heads/GEODE-2290 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=38cf13f ]

GEODE-2553: Closed IndexRepositories when deleting an index


> After deleting and recreating my Lucene index and region, my Lucene query 
> hung.
> ---
>
> Key: GEODE-2553
> URL: https://issues.apache.org/jira/browse/GEODE-2553
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
> Fix For: 1.2.0
>
> Attachments: server50505.log, stack.log
>
>
> While manually testing in gfsh the process of deleting Lucene indexes, 
> deleting the region, creating new indexes and a new empty region, I was able 
> to hang gfsh while doing a Lucene search on the new region with no data.
> Here are the steps I used:
> _ __
>/ _/ __/ __/ // /
>   / /  __/ /___  /_  / _  / 
>  / /__/ / /  _/ / // /  
> /__/_/  /__/_//_/1.2.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> gfsh>start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> gfsh>create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>put --key=1 --value=value1 --region=testRegion
> gfsh>put --key=2 --value=value2 --region=testRegion
> gfsh>put --key=3 --value=value3 --region=testRegion
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>destroy lucene index --region=/testRegion --name=testIndex
> gfsh>list lucene indexes --with-stats
> gfsh>search lucene --name=testIndex2 --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> 
> gfsh>destroy lucene index --region=/testRegion
> gfsh>list lucene indexes --with-stats
> gfsh>destroy region --name=/testRegion
> gfsh>create lucene index --name=testIndex --region=testRegion 
> gfsh>create lucene index --name=testIndex2 --region=testRegion 
> --field=__REGION_VALUE_FIELD
> gfsh>list lucene indexes --with-stats
> gfsh>create region --name=testRegion --type=PARTITION_PERSISTENT
> gfsh>search lucene --name=testIndex --region=/testRegion 
> --queryStrings=value* --defaultField=__REGION_VALUE_FIELD
> The gfsh process hangs at this point.
> I'll attach the stacktrace for the server.



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

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


Commit cfaa0e79548f06483b5c036fc3ef04951e6bcef4 in geode's branch 
refs/heads/GEODE-2290 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=cfaa0e7 ]

GEODE-2539: revert jetty version change for now


> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(Redirec

[jira] [Commented] (GEODE-2616) A colocated paritioned region will leak memory when it is closed or destroyed

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2616:


Commit a0716a57b19f330c991d8bc8d77a8b7b4352ed86 in geode's branch 
refs/heads/GEODE-2290 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a0716a5 ]

GEODE-2616: fix leak in colocated region removal

postDestroyRegion now removes itself from colocated parent colocatedByList


> A colocated paritioned region will leak memory when it is closed or destroyed
> -
>
> Key: GEODE-2616
> URL: https://issues.apache.org/jira/browse/GEODE-2616
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Affects Versions: 1.1.0
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.2.0
>
>
> When a colocated partitioned region is created it registers itself with the 
> parent region it is colocated with. When that same region is closed or 
> destroyed it does not deregister itself from the parent.
> This results in a memory leak that remains until the parent region is itself 
> closed or destroyed.



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

Split geode nightly build into two jobs

[Kirk Lund]

I'd like to propose splitting the Geode Nightly build into two jobs:

1) precheckin without flakyTest
2) flakyTest by itself

[jira] [Assigned] (GEODE-2646) PulseDataExportTest.dataBrowserExportWorksAsExpected fails with BindException

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2646:


Assignee: Kirk Lund

> PulseDataExportTest.dataBrowserExportWorksAsExpected fails with BindException
> -
>
> Key: GEODE-2646
> URL: https://issues.apache.org/jira/browse/GEODE-2646
> Project: Geode
>  Issue Type: Bug
>  Components: pulse, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> {noformat}
> :geode-assembly:flakyTest
> org.apache.geode.tools.pulse.PulseDataExportTest > 
> dataBrowserExportWorksAsExpected FAILED
> java.lang.AssertionError: Suspicious strings were written to the log 
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 1371
> [error 2017/03/08 04:58:14.240 UTC  tid=0x31] 
> Jmx manager could not be started because java.rmi.server.ExportException: 
> Port already in use: 1099; nested exception is:
> java.net.BindException: Failed to create server socket on  null[1,099]
> org.apache.geode.management.ManagementException: 
> java.rmi.server.ExportException: Port already in use: 1099; nested exception 
> is:
> java.net.BindException: Failed to create server socket on  null[1,099]
> at 
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:149)
> at 
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:469)
> at 
> org.apache.geode.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:105)
> at 
> org.apache.geode.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:55)
> at 
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1318)
> at 
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:392)
> 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.rmi.server.ExportException: Port already in use: 1099; 
> nested exception is:
> java.net.BindException: Failed to create server socket on  null[1,099]
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341)
> at 
> sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249)
> at 
> sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
> at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
> at 
> sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
> at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:195)
> at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:155)
> at 
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239)
> at 
> org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:398)
> at 
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:147)
> ... 8 more
> Caused by: java.net.BindException: Failed to create server socket on  
> null[1,099]
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:739)
> at 
> org.apache.geode.management.internal.ManagementAgent$GemFireRMIServerSocketFactory.createServerSocket(ManagementAgent.java:556)
> at 
> sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666)
> at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330)
> ... 17 more
> Caused by: java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at 
> java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:778)
> ... 21 more
> 2 tests completed, 1 failed
> {noformat}



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

[jira] [Created] (GEODE-2646) PulseDataExportTest.dataBrowserExportWorksAsExpected fails with BindException

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2646:


 Summary: PulseDataExportTest.dataBrowserExportWorksAsExpected 
fails with BindException
 Key: GEODE-2646
 URL: https://issues.apache.org/jira/browse/GEODE-2646
 Project: Geode
  Issue Type: Bug
  Components: pulse, tests
Reporter: Kirk Lund


{noformat}
:geode-assembly:flakyTest

org.apache.geode.tools.pulse.PulseDataExportTest > 
dataBrowserExportWorksAsExpected FAILED
java.lang.AssertionError: Suspicious strings were written to the log during 
this run.
Fix the strings or use IgnoredException.addIgnoredException to ignore.
---
Found suspect string in log4j at line 1371

[error 2017/03/08 04:58:14.240 UTC  tid=0x31] 
Jmx manager could not be started because java.rmi.server.ExportException: Port 
already in use: 1099; nested exception is:
java.net.BindException: Failed to create server socket on  null[1,099]
org.apache.geode.management.ManagementException: 
java.rmi.server.ExportException: Port already in use: 1099; nested exception is:
java.net.BindException: Failed to create server socket on  null[1,099]
at 
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:149)
at 
org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:469)
at 
org.apache.geode.management.internal.JmxManagerLocator.findJmxManager(JmxManagerLocator.java:105)
at 
org.apache.geode.management.internal.JmxManagerLocator.processRequest(JmxManagerLocator.java:55)
at 
org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1318)
at 
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:392)
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.rmi.server.ExportException: Port already in use: 1099; 
nested exception is:
java.net.BindException: Failed to create server socket on  null[1,099]
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:341)
at 
sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:249)
at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
at 
sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:234)
at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:195)
at sun.rmi.registry.RegistryImpl.(RegistryImpl.java:155)
at 
java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:239)
at 
org.apache.geode.management.internal.ManagementAgent.configureAndStart(ManagementAgent.java:398)
at 
org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:147)
... 8 more
Caused by: java.net.BindException: Failed to create server socket on  
null[1,099]
at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:739)
at 
org.apache.geode.management.internal.ManagementAgent$GemFireRMIServerSocketFactory.createServerSocket(ManagementAgent.java:556)
at 
sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666)
at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:330)
... 17 more
Caused by: java.net.BindException: Address already in use (Bind failed)
at java.net.PlainSocketImpl.socketBind(Native Method)
at 
java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
at java.net.ServerSocket.bind(ServerSocket.java:375)
at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:778)
... 21 more

2 tests completed, 1 failed
{noformat}




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

Re: Split geode nightly build into two jobs

[Dan Smith]

+1

-Dan

On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:

> I'd like to propose splitting the Geode Nightly build into two jobs:
>
> 1) precheckin without flakyTest
> 2) flakyTest by itself
>

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

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2647:


Assignee: Kirk Lund

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

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

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2647:


 Summary: 
ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled fails with 
NullPointerException
 Key: GEODE-2647
 URL: https://issues.apache.org/jira/browse/GEODE-2647
 Project: Geode
  Issue Type: Bug
  Components: jmx, tests
Reporter: Kirk Lund


{noformat}
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.management.ClientHealthStatsDUnitTest$$Lambda$193/1653332728.run
 in VM 3 running on Host asf902.gq1.ygridcore.net with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.management.ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled(ClientHealthStatsDUnitTest.java:128)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at 
org.apache.geode.management.ManagementTestRule$2.evaluate(ManagementTestRule.java:86)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at 
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at 
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at 
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at 
org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 
org.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.NullPointerException
at 
o

Re: Review Request 57514: GEODE-2267: enhance error output for gfsh.

[Kirk Lund]

> On March 13, 2017, 5:47 p.m., Kirk Lund wrote:
> > I think we renamed the tests but missed ExportLogsCommand.java.

My review includes a Ship It! But the GUI is showing it under "Fix It!"


- Kirk


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


On March 13, 2017, 5:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57514/
> ---
> 
> (Updated March 13, 2017, 5:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * correctly output error message if gfsh execution has an error
> * export logs should output correct log message over http connection as well
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  36d071c153ed8c2559cc8c29e248058b42cbf7ff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  0351573f6eda80e1751bd6b95efdbe6ce36a620d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
>  b7f8c2a080614ab59dc9da29c31f606749b58e4a 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/web/controllers/ExportLogControllerTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  f3674581d6e27bba8932294152cc2db8727a4024 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
>  cc4ae28ff97fc50c3a9298ea3355847008776ec3 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57514/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running ...
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 57514: GEODE-2267: enhance error output for gfsh.

[Kirk Lund]

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


Fix it, then Ship it!




I think we renamed the tests but missed ExportLogsCommand.java.


geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
Line 53 (original), 53 (patched)


I thought we renamed this to ExportLogsCommand.java?


- Kirk Lund


On March 13, 2017, 5:32 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57514/
> ---
> 
> (Updated March 13, 2017, 5:32 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, Kirk Lund, 
> and Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * correctly output error message if gfsh execution has an error
> * export logs should output correct log message over http connection as well
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogCommand.java
>  36d071c153ed8c2559cc8c29e248058b42cbf7ff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  0351573f6eda80e1751bd6b95efdbe6ce36a620d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportStatsDUnitTest.java
>  b7f8c2a080614ab59dc9da29c31f606749b58e4a 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/web/controllers/ExportLogControllerTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  f3674581d6e27bba8932294152cc2db8727a4024 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
>  cc4ae28ff97fc50c3a9298ea3355847008776ec3 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpIntegrationTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/57514/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running ...
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Assigned] (GEODE-2648) DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with TimeoutException

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2648:


Assignee: Kirk Lund

> DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with 
> TimeoutException
> ---
>
> Key: GEODE-2648
> URL: https://issues.apache.org/jira/browse/GEODE-2648
> Project: Geode
>  Issue Type: Bug
>  Components: statistics, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> {noformat}
> java.util.concurrent.TimeoutException: File 
> /tmp/junit460899251228048267/aboveZeroDeletesPreviousFiles-02-01.gfs does not 
> exist after 5559 samples within 1 MINUTES
>   at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.sampleUntilFileExists(DiskSpaceLimitIntegrationTest.java:285)
>   at 
> org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles(DiskSpaceLimitIntegrationTest.java:199)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.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: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.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
>   at 
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
>   at 
> org.gradle.internal.remote.internal.hub.Messa

[jira] [Created] (GEODE-2648) DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with TimeoutException

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2648:


 Summary: 
DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles fails with 
TimeoutException
 Key: GEODE-2648
 URL: https://issues.apache.org/jira/browse/GEODE-2648
 Project: Geode
  Issue Type: Bug
  Components: statistics, tests
Reporter: Kirk Lund


{noformat}
java.util.concurrent.TimeoutException: File 
/tmp/junit460899251228048267/aboveZeroDeletesPreviousFiles-02-01.gfs does not 
exist after 5559 samples within 1 MINUTES
at 
org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.sampleUntilFileExists(DiskSpaceLimitIntegrationTest.java:285)
at 
org.apache.geode.internal.statistics.DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles(DiskSpaceLimitIntegrationTest.java:199)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.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: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.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at 
org.gradle.internal.dispatch.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(ThreadPoolExec

Re: Review Request 57439: GEODE-2576: delete the zip file on locator after it's being streamed to client.

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On March 8, 2017, 4:44 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57439/
> ---
> 
> (Updated March 8, 2017, 4:44 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2576: delete the zip file on locator after it's being streamed to 
> client.
> 
> * also modified a couple tests to use the rules more efficiently.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  f3a59340f0d88d8fb1d24e4db2f95c3ffd7c2fa0 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunctionIntegrationTest.java
>  72c39dc173b2bde2f8a5d6e034baf5d1cd555725 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsOverHttpDUnitTest.java
>  8c9442a11b08c1e2e66cc7d424388f19642655d8 
>   
> geode-web/src/test/java/org/apache/geode/management/internal/cli/commands/QueryNamesOverHttpDUnitTest.java
>  4ec9c0d35a029af14de511b7ae19688b7e4da0a3 
> 
> 
> Diff: https://reviews.apache.org/r/57439/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 57466: GEODE-2632: check if it is integrated security early in the call

[Jinmei Liao]

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

(Updated March 13, 2017, 5:54 p.m.)


Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk Lund.


Changes
---

restore the overridden methods. do the string manipulation and object creation 
later in the call.


Repository: geode


Description
---

* clean up interface, reduce function call


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 8366930a3bf6a244d077c745fc810d77c4699c38 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 


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

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


Testing (updated)
---

precheckin running


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kevin Duling (JIRA)]

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

Kevin Duling commented on GEODE-2539:
-

Per discussion on dev list, we are only upgrading to 9.3.11.v20160721 for now 
due to API changes.

> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> ... 4 more
> 38 tests co

[jira] [Created] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2649:


 Summary: 
ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
AssertionError
 Key: GEODE-2649
 URL: https://issues.apache.org/jira/browse/GEODE-2649
 Project: Geode
  Issue Type: Bug
  Components: gfsh, tests
Reporter: Kirk Lund


{noformat}
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
testExportWithStartAndEndDateTimeFiltering FAILED
java.lang.AssertionError:
Expected size:<3> but was:<2> in:
<[/tmp/junit8723178147444223944/unzippedLogs/server-1,
/tmp/junit8723178147444223944/unzippedLogs/server-2]>
at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
at 
org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)

303 tests completed, 1 failed, 8 skipped
{noformat}



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

[jira] [Assigned] (GEODE-2649) ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with AssertionError

[Kirk Lund (JIRA)]

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

Kirk Lund reassigned GEODE-2649:


Assignee: Jared Stewart

> ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering fails with 
> AssertionError
> 
>
> Key: GEODE-2649
> URL: https://issues.apache.org/jira/browse/GEODE-2649
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tests
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest > 
> testExportWithStartAndEndDateTimeFiltering FAILED
> java.lang.AssertionError:
> Expected size:<3> but was:<2> in:
> <[/tmp/junit8723178147444223944/unzippedLogs/server-1,
> /tmp/junit8723178147444223944/unzippedLogs/server-2]>
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.verifyZipFileContents(ExportLogsDUnitTest.java:225)
> at 
> org.apache.geode.management.internal.cli.commands.ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering(ExportLogsDUnitTest.java:155)
> 303 tests completed, 1 failed, 8 skipped
> {noformat}



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

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


Commit 02ffd528f5136cb8fe3acfd29f91369901bf15de in geode's branch 
refs/heads/develop from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=02ffd52 ]

GEODE-2539: Upgrading Jetty causes RestSecurityIntegrationTest to fail (#2)


> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.Red

Geode Nightly build failures

[Kirk Lund]

I'm working on these failures from the last 4 days:

GEODE-2648 - DiskSpaceLimitIntegrationTest.aboveZeroDeletesPreviousFiles -
race condition in test
GEODE-2647
- ClientHealthStatsDUnitTest.testClientHealthStats_SubscriptionEnabled -
race condition in test
GEODE-2646 - PulseDataExportTest.dataBrowserExportWorksAsExpected - use of
default port

Jared is working on this one:

GEODE-2649 - ExportLogsDUnitTest.testExportWithStartAndEndDateTimeFiltering

All 4 appear to be flakiness in the tests.

[jira] [Resolved] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-2539.
-
Resolution: Fixed

> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> ... 4 more
> 38 tests completed, 2 failed
> :geode-assembly:integrationTest FAILED
> {noformat}



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

[jira] [Created] (GEODE-2650) Need an integration test to scan logs for clear-text passwords

[Kevin Duling (JIRA)]

Kevin Duling created GEODE-2650:
---

 Summary: Need an integration test to scan logs for clear-text 
passwords
 Key: GEODE-2650
 URL: https://issues.apache.org/jira/browse/GEODE-2650
 Project: Geode
  Issue Type: Improvement
  Components: gfsh, logging
Reporter: Kevin Duling


This issue keeps creeping up, so it would be good to have a test that scans log 
files for any password in the clear.



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

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling]

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

(Updated March 13, 2017, 11:05 a.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.


Repository: geode


Description
---

GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
clear text


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
742e7f3e93e595844675d0789b995e4ceb4431ac 
  geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
419f3f976159e601c95a2042bafd96cc9fe9465f 


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


Testing (updated)
---

precheckin completed


Thanks,

Kevin Duling

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling]

> On March 8, 2017, 1:16 p.m., Jinmei Liao wrote:
> > Any test changes? We probably can create a integrated/dunit test that would 
> > start a server with those ssl properties (including passwords) turned on, 
> > and have debug level truned on, and security truned on as well, and have 
> > gfsh connect to it using username and password, and see if any of the 
> > password show up in the logs.
> 
> Kevin Duling wrote:
> `ArgumentRedactorJUnitTest` already has 85% method coverage and 95% line 
> coverage of `ArgumentRedactor`.  `SocketCreator.printConfig()` is a void 
> method which only writes out to the log file.  I could add a specific test 
> for the expected ssl property, but it's already covered by the comparison 
> `compareKey.toLowerCase().contains("password");`
> 
> Jinmei Liao wrote:
> ArugmentRedactor is defintely doing the right thing since we have test 
> coverage on that. It's the SocketCreator that is the problem here.
> 
> Kevin Duling wrote:
> I disagree.  ArgumentRedactor just has to populate the StringBuilder with 
> the correct string.  The only additional piece is calling the logger to write 
> the file, which is Log4J, not SocketCreator.  I'm not clear on what 
> additional testing would prove.
> 
> `RestSecurityWithSSLTest` is probably a good test to work from as it is 
> an entry point for this code.
> 
> Jared Stewart wrote:
> I think the goal of a test for SocketCreator would be that if someone 
> reverts the changes to SocketCreator made by this commit, there should be a 
> test that fails.
> 
> Jinmei Liao wrote:
> My point as well. We should have a test that would fail without your 
> changes in SocketCreator, and then passes when you put in the fix.
> 
> Kirk Lund wrote:
> We really need to move away from writing lots of additional DUnit tests. 
> Instead, write a true unit test if you're going to write further tests. I'm 
> available to pair on this to help come up with a meaningful unit test that is 
> NOT a DUnit test.

I've opened https://issues.apache.org/jira/browse/GEODE-2650 for a more generic 
test to scan for clear-text passwords.


- Kevin


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


On March 8, 2017, 12:58 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 8, 2017, 12:58 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

TSU NOTIFICATION - Encryption

[Mark Bretl]

SUBMISSION TYPE: TSU

SUBMITTED BY: Mark Bretl

SUBMITTED FOR: The Apache Software Foundation

POINT OF CONTACT: Secretary, The Apache Software Foundation

FAX: +1-919-573-9199

MANUFACTURER(S): The Apache Software Foundation, Oracle, The OpenSSL
Project

PRODUCT NAME/MODEL #: Apache Geode

ECCN: 5D002

NOTIFICATION: http://www.apache.org/licenses/exports/

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On March 13, 2017, 6:05 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 13, 2017, 6:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin completed
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

Re: Export Control for Geode

[Mark Bretl]

HI Anthony,

Sorry for the delay, I have completed steps #1 and #2.

--Mark

On Mon, Mar 6, 2017 at 10:42 AM, Anthony Baker  wrote:

> Thanks Mark!  Let me know if you have any questions.
>
> Anthony
>
> > On Mar 6, 2017, at 10:32 AM, Mark Bretl  wrote:
> >
> > Looks good. Unless there are any other comments/issues, I will start this
> > tomorrow.
> >
> > --Mark
> >
> > On Thu, Mar 2, 2017 at 10:29 PM, Anthony Baker 
> wrote:
> >
> >> After reviewing [1], I think we need to record and report our use of
> >> cryptographic libraries that fall under US export control.
> >>
> >> This means:
> >>
> >> 1) Updating the eccnmatrix.xml [2] in svn and publishing the change [3].
> >> 2) Sending an email [4].
> >> 3) Updating README.md [5].
> >>
> >> Mark, #1 and #2 need to be done by the PMC Chair.  Can you review this
> >> and let me know what you think?  I can tackle #3 after.
> >>
> >> Thanks,
> >> Anthony
> >>
> >> [1] http://www.apache.org/dev/crypto.html
> >> [2] https://gist.github.com/metatype/96da9d928f20d5ae638cc16dd4ee9a85
> >> [3] https://cms.apache.org/www/publish
> >> [4] https://gist.github.com/metatype/24b4462af6319cbf568b63ad3a56464e
> >> [5] https://gist.githubusercontent.com/metatype/
> >> b50b49a4c2a7a99793029b3ea0cde8c3/raw/40aca011a65c12d6fbec73fce60f57
> >> f43323d36f/README.md
> >>
>
>

[jira] [Resolved] (GEODE-2354) Use of security-manager results in UnknownSessionExceptions after 30 minutes idle

[Jinmei Liao (JIRA)]

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

Jinmei Liao resolved GEODE-2354.

Resolution: Fixed

> Use of security-manager results in UnknownSessionExceptions after 30 minutes 
> idle
> -
>
> Key: GEODE-2354
> URL: https://issues.apache.org/jira/browse/GEODE-2354
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>Assignee: Jinmei Liao
>
> If the User specifies a SecurityManager with security-manager, all authorized 
> operations start to fail with UnknownSessionExceptions after 30 minutes idle 
> which is the default globalSessionTimeout in Apache Shiro.
> Workaround: specify security-shiro-init in gemfire.properties and configure 
> everything via Shiro within a shiro.ini.
> Fixing this will require changes to IntegratedSecurityService to set the 
> globalSessionTimeout higher or to re-authenticate after a timeout.



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

[jira] [Created] (GEODE-2651) Function service should provide built-in mechanism for streaming back large function results

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-2651:


 Summary: Function service should provide built-in mechanism for 
streaming back large function results
 Key: GEODE-2651
 URL: https://issues.apache.org/jira/browse/GEODE-2651
 Project: Geode
  Issue Type: Improvement
  Components: functions
Reporter: Jared Stewart


It would be convenient to have a built-in mechanism for streaming back large 
function results that does not require keeping all results in memory on either 
end of the function execution.  Example use cases: 

- Executing a function to gather all logs on server (this may produce a very 
large zip file)
- Executing netstat -lsof currently runs out of memory in CI



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

[jira] [Commented] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao commented on GEODE-2605:


Created this dunit test to verify the behavior. the test is passing because the 
LuceneIndexCommand declares that searchIndex requires "cluster:read".



public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:01 PM:
-

Created this dunit test to verify the behavior. 

public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}



was (Author: jinmeiliao):
Created this dunit test to verify the behavior. the test is passing because the 
LuceneIndexCommand declares that searchIndex requires "cluster:read".



public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:03 PM:
-

Created this dunit test to verify the behavior. 
{{
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

}}



was (Author: jinmeiliao):
Created this dunit test to verify the behavior. 

public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:04 PM:
-

Created this dunit test to verify the behavior. 
{quote}
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

{quote}



was (Author: jinmeiliao):
Created this dunit test to verify the behavior. 
{{
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

}}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:06 PM:
-

Created this dunit test to verify the behavior. 
{quote}
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

{quote}

This passes because in LuceneIndexCommand, the searchIndex command is annotated 
as requiring "cluster:read" permission:

{quote}
  @ResourceOperation(resource = Resource.CLUSTER, operation = Operation.READ)
{quote}



was (Author: jinmeiliao):
Created this dunit test to verify the behavior. 
{quote}
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

{quote}

This passes because in LuceneIndexCommand, the searchIndex command is annotated 
as requiring "cluster:read" permission:

{quote}
  @CliCommand(value = LuceneCliStrings.LUCENE_DESTROY_INDEX,
  help = LuceneCliStrings.LUCENE_DESTROY_INDEX__HELP)
  @CliMetaData(shellOnly = false,
  relatedTopic = {CliStrings.TOPIC_GEODE_REGION, 
CliStrings.TOPIC_GEODE_DATA})
  @ResourceOperation(resource = Resource.CLUSTER, operation = Operation.READ)
{quote}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Comment Edited] (GEODE-2605) Unable to do a Lucene query without CLUSTER:READ privilege

[Jinmei Liao (JIRA)]

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

Jinmei Liao edited comment on GEODE-2605 at 3/13/17 7:05 PM:
-

Created this dunit test to verify the behavior. 
{quote}
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

{quote}

This passes because in LuceneIndexCommand, the searchIndex command is annotated 
as requiring "cluster:read" permission:

{quote}
  @CliCommand(value = LuceneCliStrings.LUCENE_DESTROY_INDEX,
  help = LuceneCliStrings.LUCENE_DESTROY_INDEX__HELP)
  @CliMetaData(shellOnly = false,
  relatedTopic = {CliStrings.TOPIC_GEODE_REGION, 
CliStrings.TOPIC_GEODE_DATA})
  @ResourceOperation(resource = Resource.CLUSTER, operation = Operation.READ)
{quote}



was (Author: jinmeiliao):
Created this dunit test to verify the behavior. 
{quote}
public class LuceneSecuritydUnitTest {

  @Rule
  public LocatorServerStartupRule lsRule = new LocatorServerStartupRule();

  @Rule
  public GfshShellConnectionRule gfsh = new GfshShellConnectionRule();

  @Test
  public void test() throws Exception{

Properties locatorProps = new Properties();
locatorProps.setProperty(SECURITY_MANAGER, 
SimpleTestSecurityManager.class.getName());
MemberVM locator = lsRule.startLocatorVM(0, locatorProps);

Properties serverProps = new Properties();
serverProps.setProperty("security-username", "cluster");
serverProps.setProperty("security-password", "cluster");
MemberVM server = lsRule.startServerVM(1, serverProps, locator.getPort());

gfsh.connectAndVerify(locator, "user", "data", "password", "data");

gfsh.executeAndVerifyCommand("create lucene index --name=testIndex 
--region=testRegion --field=__REGION_VALUE_FIELD");
gfsh.executeAndVerifyCommand("create region --name=testRegion 
--type=PARTITION_PERSISTENT");
gfsh.executeAndVerifyCommand("put --key=1 --value=value1 
--region=testRegion");
String result = gfsh.execute("search lucene --name=testIndex 
--region=testRegion --queryStrings=value* --defaultField=__REGION_VALUE_FIELD");

assertThat(result).contains("Unauthorized. Reason : data not authorized for 
CLUSTER:READ");
  }
}

{quote}


> Unable to do a Lucene query without CLUSTER:READ privilege
> --
>
> Key: GEODE-2605
> URL: https://issues.apache.org/jira/browse/GEODE-2605
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene, security
>Reporter: Diane Hardman
> Attachments: security.json
>
>
> I have configured a small cluster with security and am testing the privileges 
> I need for creating a Lucene index and then executing a query/search using 
> Lucene. 
> I have confirmed that DATA:MANAGE privilege allows me to create a lucene 
> index (similar to creating OQL indexes).
> I assumed I needed DATA:WRITE privilege to execute 'search lucene' because 
> the implementation uses a function. Instead, I am getting an error that I 
> need CLUSTER:READ privilege. I don't know why.
> As an aside, we may want to document that all DATA privileges automatically 
> include CLUSTER:READ as I found I could create indexes with DATA:WRITE, but 
> could not list the indexes I created without CLUSTER:READ... go figure.



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

[jira] [Commented] (GEODE-2548) Hang in PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2548:


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

GEODE-2548: Removing the test 
alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults

* Removed the test as it was shutting down one datastore before the 
other datastore could recover from it.
* The second datastore just keeps waiting (hang) to recover but the 
other datastore was shut down


> Hang in 
> PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults
> ---
>
> Key: GEODE-2548
> URL: https://issues.apache.org/jira/browse/GEODE-2548
> Project: Geode
>  Issue Type: Test
>  Components: lucene
>Reporter: Jason Huynh
>
> There is possibly a race condition in starting/stopping the caches with 
> persistent regions.
> It appears to hang with this in the logs:
> [vm0] [info 2017/02/24 16:44:56.609 PST  AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE> tid=0x49] Region 
> /region (and any colocated sub-regions) has potentially stale data.  Buckets 
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] are waiting for another offline member to 
> recover the latest data.
> [vm0] My persistent id is:
> [vm0]   DiskStore ID: 110901a3-8e42-4d25-a1ee-4ead6f966a29
> [vm0]   Name: 
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm0/.
> [vm0] Offline members with potentially new data:
> [vm0] [
> [vm0]   DiskStore ID: 582f64c5-d53b-463c-a6a5-b4a0bea79381
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm1/.
> [vm0]   Buckets: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> [vm0] ]
> [vm0] Use the "gfsh show missing-disk-stores" command to see all disk stores 
> that are being waited on by other members.
> [vm0] 19.470: [GC (Allocation Failure) [PSYoungGen: 72510K->9170K(76288K)] 
> 76117K->12784K(251392K), 0.0057840 secs] [Times: user=0.02 sys=0.00, 
> real=0.00 secs] 
> [vm0] [warn 2017/02/24 16:45:03.778 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:45:33.783 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:46:03.786 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:03.791 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:33.794 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:03.796 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:33.799 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:03.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:33.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offlin

[jira] [Resolved] (GEODE-2548) Hang in PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults

[nabarun (JIRA)]

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

nabarun resolved GEODE-2548.

Resolution: Fixed

The test was removed.

> Hang in 
> PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults
> ---
>
> Key: GEODE-2548
> URL: https://issues.apache.org/jira/browse/GEODE-2548
> Project: Geode
>  Issue Type: Test
>  Components: lucene
>Reporter: Jason Huynh
>
> There is possibly a race condition in starting/stopping the caches with 
> persistent regions.
> It appears to hang with this in the logs:
> [vm0] [info 2017/02/24 16:44:56.609 PST  AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE> tid=0x49] Region 
> /region (and any colocated sub-regions) has potentially stale data.  Buckets 
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] are waiting for another offline member to 
> recover the latest data.
> [vm0] My persistent id is:
> [vm0]   DiskStore ID: 110901a3-8e42-4d25-a1ee-4ead6f966a29
> [vm0]   Name: 
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm0/.
> [vm0] Offline members with potentially new data:
> [vm0] [
> [vm0]   DiskStore ID: 582f64c5-d53b-463c-a6a5-b4a0bea79381
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm1/.
> [vm0]   Buckets: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> [vm0] ]
> [vm0] Use the "gfsh show missing-disk-stores" command to see all disk stores 
> that are being waited on by other members.
> [vm0] 19.470: [GC (Allocation Failure) [PSYoungGen: 72510K->9170K(76288K)] 
> 76117K->12784K(251392K), 0.0057840 secs] [Times: user=0.02 sys=0.00, 
> real=0.00 secs] 
> [vm0] [warn 2017/02/24 16:45:03.778 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:45:33.783 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:46:03.786 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:03.791 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:33.794 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:03.796 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:33.799 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:03.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:33.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:50:03.804 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks



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

Re: Split geode nightly build into two jobs

[Anilkumar Gingade]

I like the idea...But, it will be nice to a single report...When the jobs
are split, there may be tendency to ignore the flaky-test runs

Other option is to: run all non-flaky tests first and then flaky-tests...

-Anil.


On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:

> I'd like to propose splitting the Geode Nightly build into two jobs:
>
> 1) precheckin without flakyTest
> 2) flakyTest by itself
>

[GitHub] geode-native pull request #52: GEODE-2513 Rename gfcpp.properties file to ge...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-2513 Rename gfcpp.properties file to geode.properties - updated…

… references, moved and renamed files

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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-PropFile

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

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


commit 35b7fca6e142a08a8976806621d58785117c2765
Author: Dave Barnes 
Date:   2017-03-13T18:24:17Z

GEODE-2513 Rename gfcpp.properties file to geode.properties - updated 
references, moved and renamed files




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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davebarnes97 opened a pull request:

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

GEODE-2513 Rename gfcpp.properties file to geode.properties - updated…

… references, moved and renamed files

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

$ git pull https://github.com/davebarnes97/geode-native 
feature/GEODE-2513-PropFile

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

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


commit 35b7fca6e142a08a8976806621d58785117c2765
Author: Dave Barnes 
Date:   2017-03-13T18:24:17Z

GEODE-2513 Rename gfcpp.properties file to geode.properties - updated 
references, moved and renamed files




> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

Fixed: apache/geode#2211 (GEODE-2290 - 5934e7e)

[Travis CI]

Build Update for apache/geode
-

Build: #2211
Status: Fixed

Duration: 7 minutes and 30 seconds
Commit: 5934e7e (GEODE-2290)
Author: Jared Stewart
Message: GEODE-2290: Remove JarClassLoader

Cherry pick test from lazy loading branch

Enhance DeployCommandRedeployDUnitTest

Fixed backup of user jars

Fixed deploy tests

Fixed undeploy test

View the changeset: 
https://github.com/apache/geode/compare/02fac310052f...5934e7e39751

View the full build log and details: 
https://travis-ci.org/apache/geode/builds/210650738

--

You can configure recipients for build notifications in your .travis.yml file. 
See https://docs.travis-ci.com/user/notifications

[jira] [Commented] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2633:


Commit 006681bad60c12635b274eb23839560b6e6147ec in geode's branch 
refs/heads/develop from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=006681b ]

GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
clear text


> When turning on fine logging, GEODE logs the keystore password in clear text
> 
>
> Key: GEODE-2633
> URL: https://issues.apache.org/jira/browse/GEODE-2633
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, logging
>Reporter: Kevin Duling
>Assignee: Kevin Duling
>
> When turning on fine logging GEODE logs the keystore password in clear text.



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

[jira] [Resolved] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-2633.
-
   Resolution: Fixed
Fix Version/s: 1.2.0

> When turning on fine logging, GEODE logs the keystore password in clear text
> 
>
> Key: GEODE-2633
> URL: https://issues.apache.org/jira/browse/GEODE-2633
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, logging
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> When turning on fine logging GEODE logs the keystore password in clear text.



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

Re: [VOTE] Marking Redis Adapter as Experimental

[Galen M O'Sullivan]

I'm going to go ahead and do this tomorrow if there are no objections.

On Wed, Mar 8, 2017 at 2:39 PM, Dan Smith  wrote:

> +1 for marking it experimental and going ahead with changing it.
>
> -Dan
>
> On Wed, Mar 8, 2017 at 2:21 PM, Michael Stolz  wrote:
>
>> +1 to marking it experimental now
>>
>> Once we do that I think it will be fine for the community to make breaking
>> changes to it if we need to.
>>
>> --
>> Mike Stolz
>> Principal Engineer, GemFire Product Manager
>> Mobile: +1-631-835-4771
>>
>> On Wed, Mar 8, 2017 at 5:08 PM, Galen M O'Sullivan > >
>> wrote:
>>
>> > Hi all,
>> >
>> > I think that we should mark the Redis adapter as experimental. This
>> > functionality comes from the initial code grant from GemFire. It is
>> > mentioned in the "Experimental" section of the GemFire docs [1], and as
>> far
>> > as I can tell, the only reason it hasn't been marked as experimental in
>> > Geode is because no one put the annotation on when the @Experimental tag
>> > was introduced.
>> >
>> > The Redis adapter's performance on collection operations is pretty bad
>> > (think 1% of Redis on a single-server configuration), and there are some
>> > bugs outstanding (for example, [2]), so I don't think it's really ready
>> for
>> > general use.
>> >
>> > What do you all think? Is anyone out there using the Redis adapter?
>> Should
>> > it be considered breaking to change it just because it's been released
>> when
>> > it wasn't marked experimental? Should we just go ahead and change it
>> > already?
>> >
>> > Thanks,
>> > Galen
>> >
>> > [1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_ada
>> pter.html
>> > [2]: https://issues.apache.org/jira/browse/GEODE-2473
>> >
>>
>
>

Re: [VOTE] Marking Redis Adapter as Experimental

[Gregory Chase]

Based on some other recent discussions about the Redis adaptor, I would
agree this makes sense.

I don't believe its usage has been well tested or proven yet by its
intended audience.

On Mon, Mar 13, 2017 at 1:09 PM, Galen M O'Sullivan 
wrote:

> I'm going to go ahead and do this tomorrow if there are no objections.
>
> On Wed, Mar 8, 2017 at 2:39 PM, Dan Smith  wrote:
>
>> +1 for marking it experimental and going ahead with changing it.
>>
>> -Dan
>>
>> On Wed, Mar 8, 2017 at 2:21 PM, Michael Stolz  wrote:
>>
>>> +1 to marking it experimental now
>>>
>>> Once we do that I think it will be fine for the community to make
>>> breaking
>>> changes to it if we need to.
>>>
>>> --
>>> Mike Stolz
>>> Principal Engineer, GemFire Product Manager
>>> Mobile: +1-631-835-4771
>>>
>>> On Wed, Mar 8, 2017 at 5:08 PM, Galen M O'Sullivan <
>>> gosulli...@pivotal.io>
>>> wrote:
>>>
>>> > Hi all,
>>> >
>>> > I think that we should mark the Redis adapter as experimental. This
>>> > functionality comes from the initial code grant from GemFire. It is
>>> > mentioned in the "Experimental" section of the GemFire docs [1], and
>>> as far
>>> > as I can tell, the only reason it hasn't been marked as experimental in
>>> > Geode is because no one put the annotation on when the @Experimental
>>> tag
>>> > was introduced.
>>> >
>>> > The Redis adapter's performance on collection operations is pretty bad
>>> > (think 1% of Redis on a single-server configuration), and there are
>>> some
>>> > bugs outstanding (for example, [2]), so I don't think it's really
>>> ready for
>>> > general use.
>>> >
>>> > What do you all think? Is anyone out there using the Redis adapter?
>>> Should
>>> > it be considered breaking to change it just because it's been released
>>> when
>>> > it wasn't marked experimental? Should we just go ahead and change it
>>> > already?
>>> >
>>> > Thanks,
>>> > Galen
>>> >
>>> > [1]: http://gemfire.docs.pivotal.io/geode/tools_modules/redis_ada
>>> pter.html
>>> > [2]: https://issues.apache.org/jira/browse/GEODE-2473
>>> >
>>>
>>
>>
>


-- 
Greg Chase

Product team
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

Re: Split geode nightly build into two jobs

[Kirk Lund]

Right now the flaky tests are NOT part of the nightly build report.
However, they can make it fail. At present, if only flaky tests fail, then
it generates errors in console output but the test results page says zero
tests fail. And we always have at least one flaky fail, so we never get a
green build.


On Mon, Mar 13, 2017 at 12:22 PM, Anilkumar Gingade 
wrote:

> I like the idea...But, it will be nice to a single report...When the jobs
> are split, there may be tendency to ignore the flaky-test runs
>
> Other option is to: run all non-flaky tests first and then flaky-tests...
>
> -Anil.
>
>
> On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:
>
> > I'd like to propose splitting the Geode Nightly build into two jobs:
> >
> > 1) precheckin without flakyTest
> > 2) flakyTest by itself
> >
>

Re: Split geode nightly build into two jobs

[Anthony Baker]

We won’t get notifications from successful builds (which should happen always 
except for newly introduced issues).

So you’ll only get notified of flaky test failures.

++1

Anthony

> On Mar 13, 2017, at 1:32 PM, Kirk Lund  wrote:
> 
> Right now the flaky tests are NOT part of the nightly build report.
> However, they can make it fail. At present, if only flaky tests fail, then
> it generates errors in console output but the test results page says zero
> tests fail. And we always have at least one flaky fail, so we never get a
> green build.
> 
> 
> On Mon, Mar 13, 2017 at 12:22 PM, Anilkumar Gingade 
> wrote:
> 
>> I like the idea...But, it will be nice to a single report...When the jobs
>> are split, there may be tendency to ignore the flaky-test runs
>> 
>> Other option is to: run all non-flaky tests first and then flaky-tests...
>> 
>> -Anil.
>> 
>> 
>> On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:
>> 
>>> I'd like to propose splitting the Geode Nightly build into two jobs:
>>> 
>>> 1) precheckin without flakyTest
>>> 2) flakyTest by itself
>>> 
>> 

Re: Export Control for Geode

[Anthony Baker]

No worries, thanks so much for the help!  I’ll update the README(s) as needed.

Anthony

> On Mar 13, 2017, at 11:08 AM, Mark Bretl  wrote:
> 
> HI Anthony,
> 
> Sorry for the delay, I have completed steps #1 and #2.
> 
> --Mark
> 
> On Mon, Mar 6, 2017 at 10:42 AM, Anthony Baker  wrote:
> 
>> Thanks Mark!  Let me know if you have any questions.
>> 
>> Anthony
>> 
>>> On Mar 6, 2017, at 10:32 AM, Mark Bretl  wrote:
>>> 
>>> Looks good. Unless there are any other comments/issues, I will start this
>>> tomorrow.
>>> 
>>> --Mark
>>> 
>>> On Thu, Mar 2, 2017 at 10:29 PM, Anthony Baker 
>> wrote:
>>> 
 After reviewing [1], I think we need to record and report our use of
 cryptographic libraries that fall under US export control.
 
 This means:
 
 1) Updating the eccnmatrix.xml [2] in svn and publishing the change [3].
 2) Sending an email [4].
 3) Updating README.md [5].
 
 Mark, #1 and #2 need to be done by the PMC Chair.  Can you review this
 and let me know what you think?  I can tackle #3 after.
 
 Thanks,
 Anthony
 
 [1] http://www.apache.org/dev/crypto.html
 [2] https://gist.github.com/metatype/96da9d928f20d5ae638cc16dd4ee9a85
 [3] https://cms.apache.org/www/publish
 [4] https://gist.github.com/metatype/24b4462af6319cbf568b63ad3a56464e
 [5] https://gist.githubusercontent.com/metatype/
 b50b49a4c2a7a99793029b3ea0cde8c3/raw/40aca011a65c12d6fbec73fce60f57
 f43323d36f/README.md
 
>> 
>> 

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[Kevin Duling (JIRA)]

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

Kevin Duling commented on GEODE-2539:
-

{{9.3.11.v20160721}} is still too high of a version, had to move to 
{{9.3.10.v20160621}} due to TLSv1.1 not being supported.

> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
>  

Re: Split geode nightly build into two jobs

[Jared Stewart]

+1 

- Jared

> On Mar 13, 2017, at 1:45 PM, Anthony Baker  wrote:
> 
> We won’t get notifications from successful builds (which should happen always 
> except for newly introduced issues).
> 
> So you’ll only get notified of flaky test failures.
> 
> ++1
> 
> Anthony
> 
>> On Mar 13, 2017, at 1:32 PM, Kirk Lund  wrote:
>> 
>> Right now the flaky tests are NOT part of the nightly build report.
>> However, they can make it fail. At present, if only flaky tests fail, then
>> it generates errors in console output but the test results page says zero
>> tests fail. And we always have at least one flaky fail, so we never get a
>> green build.
>> 
>> 
>> On Mon, Mar 13, 2017 at 12:22 PM, Anilkumar Gingade 
>> wrote:
>> 
>>> I like the idea...But, it will be nice to a single report...When the jobs
>>> are split, there may be tendency to ignore the flaky-test runs
>>> 
>>> Other option is to: run all non-flaky tests first and then flaky-tests...
>>> 
>>> -Anil.
>>> 
>>> 
>>> On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:
>>> 
 I'd like to propose splitting the Geode Nightly build into two jobs:
 
 1) precheckin without flakyTest
 2) flakyTest by itself
 
>>> 
> 

[jira] [Commented] (GEODE-2539) Upgrading Jetty causes RestSecurityIntegrationTest to fail

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2539:


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

GEODE-2539: Upgrading Jetty causes RestSecurityIntegrationTest to fail (#3)


> Upgrading Jetty causes RestSecurityIntegrationTest to fail
> --
>
> Key: GEODE-2539
> URL: https://issues.apache.org/jira/browse/GEODE-2539
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin), security, tests
>Reporter: Kirk Lund
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> Upgrading our jetty dependency in gradle/dependency-versions.properties:
> -jetty.version = 9.3.6.v20151106
> +jetty.version = 9.4.0.v20161208
> Causes these RestSecurityIntegrationTest tests to fail (possibly 
> intermittently):
> {noformat}
> :geode-assembly:integrationTest
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > headRegion 
> FAILED
> org.apache.http.NoHttpResponseException: localhost:21423 failed to respond
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doHEAD(GeodeRestClient.java:104)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.headRegion(RestSecurityIntegrationTest.java:246)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testServers 
> FAILED
> org.apache.http.client.ClientProtocolException
> at 
> org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186)
> at 
> org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:71)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doRequest(GeodeRestClient.java:161)
> at 
> org.apache.geode.rest.internal.web.GeodeRestClient.doGet(GeodeRestClient.java:125)
> at 
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testServers(RestSecurityIntegrationTest.java:165)
> Caused by:
> org.apache.http.ProtocolException: The server failed to respond with 
> a valid HTTP response
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:151)
> at 
> org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57)
> at 
> org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261)
> at 
> org.apache.http.impl.DefaultBHttpClientConnection.receiveResponseHeader(DefaultBHttpClientConnection.java:165)
> at 
> org.apache.http.impl.conn.CPoolProxy.receiveResponseHeader(CPoolProxy.java:167)
> at 
> org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272)
> at 
> org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124)
> at 
> org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:271)
> at 
> org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:184)
> at 
> org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:88)
> at 
> org.apache.http.impl.execchain.Red

Re: Split geode nightly build into two jobs

[Bruce Schuchardt]

+1

Le 3/13/2017 à 1:49 PM, Jared Stewart a écrit :

+1

- Jared


On Mar 13, 2017, at 1:45 PM, Anthony Baker  wrote:

We won’t get notifications from successful builds (which should happen always 
except for newly introduced issues).

So you’ll only get notified of flaky test failures.

++1

Anthony


On Mar 13, 2017, at 1:32 PM, Kirk Lund  wrote:

Right now the flaky tests are NOT part of the nightly build report.
However, they can make it fail. At present, if only flaky tests fail, then
it generates errors in console output but the test results page says zero
tests fail. And we always have at least one flaky fail, so we never get a
green build.


On Mon, Mar 13, 2017 at 12:22 PM, Anilkumar Gingade 
wrote:


I like the idea...But, it will be nice to a single report...When the jobs
are split, there may be tendency to ignore the flaky-test runs

Other option is to: run all non-flaky tests first and then flaky-tests...

-Anil.


On Mon, Mar 13, 2017 at 10:44 AM, Kirk Lund  wrote:


I'd like to propose splitting the Geode Nightly build into two jobs:

1) precheckin without flakyTest
2) flakyTest by itself

Re: Review Request 57466: GEODE-2632: check if it is integrated security early in the call

[Anthony Baker]

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




geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
Line 453 (original), 464 (patched)


How much did this change improve performance?

I didn't review all the member variables, but `isIntegratedSecurity` does 
not appear to be thread-safe.

That needs to be fixed, and then we should defintely revisit performance as 
it could introduce a contention bottleneck.


- Anthony Baker


On March 13, 2017, 5:54 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57466/
> ---
> 
> (Updated March 13, 2017, 5:54 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * clean up interface, reduce function call
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  8366930a3bf6a244d077c745fc810d77c4699c38 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
> 
> 
> Diff: https://reviews.apache.org/r/57466/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[GitHub] geode-native pull request #49: GEODE-2513 Unbrand docs section on Preserving...

[karensmolermiller]

Github user karensmolermiller closed the pull request at:

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


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

[GitHub] geode-native issue #49: GEODE-2513 Unbrand docs section on Preserving Data

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/49
  
Merged in. Closing.


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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller closed the pull request at:

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


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/49
  
Merged in. Closing.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

Re: Review Request 57466: GEODE-2632: check if it is integrated security early in the call

[Jinmei Liao]

> On March 13, 2017, 8:52 p.m., Anthony Baker wrote:
> > geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
> > Line 453 (original), 464 (patched)
> > 
> >
> > How much did this change improve performance?
> > 
> > I didn't review all the member variables, but `isIntegratedSecurity` 
> > does not appear to be thread-safe.
> > 
> > That needs to be fixed, and then we should defintely revisit 
> > performance as it could introduce a contention bottleneck.

We don't have JMH implemented for the numbers yet. Will continue to enhance 
this. This is just to get rid of the string manipulation and object creation 
before we actually check for isSecurityEnabled.

I don't see any need for isIntegratedSecurity to be thread-safe, multiple 
threads can call this method and they should arrive at the same conclusion, and 
after the flag is not null anymore, they will just do read operations. Correct 
me if I am wrong here...


- Jinmei


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


On March 13, 2017, 5:54 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57466/
> ---
> 
> (Updated March 13, 2017, 5:54 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, Ken Howe, and Kirk 
> Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * clean up interface, reduce function call
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  8366930a3bf6a244d077c745fc810d77c4699c38 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
> 
> 
> Diff: https://reviews.apache.org/r/57466/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 57431: GEODE-2633: When turning on fine logging, GEODE logs the keystore password in clear text

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On March 13, 2017, 6:05 p.m., Kevin Duling wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/57431/
> ---
> 
> (Updated March 13, 2017, 6:05 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Ken Howe, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
> clear text
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> 742e7f3e93e595844675d0789b995e4ceb4431ac 
>   
> geode-core/src/main/java/org/apache/geode/internal/util/ArgumentRedactor.java 
> 419f3f976159e601c95a2042bafd96cc9fe9465f 
> 
> 
> Diff: https://reviews.apache.org/r/57431/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin completed
> 
> 
> Thanks,
> 
> Kevin Duling
> 
>

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/52
  
Please also change the headings in the file 
setting-properties/chapter-overview.html.

The 7 link names in file setting-properties/native-client-config.html do 
not match the headings at the top (or in section header) of the linked file.  I 
would like to see them match.  Same for 1 link name in file 
setting-properties/cache-server-config.html.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[GitHub] geode-native issue #52: GEODE-2513 Rename gfcpp.properties file to geode.pro...

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode-native/pull/52
  
Please also change the headings in the file 
setting-properties/chapter-overview.html.

The 7 link names in file setting-properties/native-client-config.html do 
not match the headings at the top (or in section header) of the linked file.  I 
would like to see them match.  Same for 1 link name in file 
setting-properties/cache-server-config.html.


---
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] [Created] (GEODE-2652) IntegratedSecurityService class has state that is not thread safe

[Kirk Lund (JIRA)]

Kirk Lund created GEODE-2652:


 Summary: IntegratedSecurityService class has state that is not 
thread safe
 Key: GEODE-2652
 URL: https://issues.apache.org/jira/browse/GEODE-2652
 Project: Geode
  Issue Type: Bug
  Components: security
Reporter: Kirk Lund


The state of IntegratedSecurityService is currently not thread safe. One thread 
may set these values by invoking initSecurity, while another thread may invoke 
others methods which access these values:

*  private PostProcessor postProcessor;
*  private SecurityManager securityManager;
*  private Boolean isIntegratedSecurity;
*  private boolean isClientAuthenticator; // is there a 
SECURITY_CLIENT_AUTHENTICATOR
* private boolean isPeerAuthenticator; // is there a SECURITY_PEER_AUTHENTICATOR




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

[jira] [Updated] (GEODE-2652) IntegratedSecurityService class has state that is not thread safe

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2652:
-
Description: 
The state of IntegratedSecurityService is currently not thread safe. One thread 
may set these values by invoking initSecurity, while others threads invoke 
methods which access these values:

*  private PostProcessor postProcessor;
*  private SecurityManager securityManager;
*  private Boolean isIntegratedSecurity;
*  private boolean isClientAuthenticator; // is there a 
SECURITY_CLIENT_AUTHENTICATOR
* private boolean isPeerAuthenticator; // is there a SECURITY_PEER_AUTHENTICATOR

This could manifest as thread visibility bugs (other thread does not see the 
value set by another thread).

  was:
The state of IntegratedSecurityService is currently not thread safe. One thread 
may set these values by invoking initSecurity, while another thread may invoke 
others methods which access these values:

*  private PostProcessor postProcessor;
*  private SecurityManager securityManager;
*  private Boolean isIntegratedSecurity;
*  private boolean isClientAuthenticator; // is there a 
SECURITY_CLIENT_AUTHENTICATOR
* private boolean isPeerAuthenticator; // is there a SECURITY_PEER_AUTHENTICATOR



> IntegratedSecurityService class has state that is not thread safe
> -
>
> Key: GEODE-2652
> URL: https://issues.apache.org/jira/browse/GEODE-2652
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Kirk Lund
>
> The state of IntegratedSecurityService is currently not thread safe. One 
> thread may set these values by invoking initSecurity, while others threads 
> invoke methods which access these values:
> *  private PostProcessor postProcessor;
> *  private SecurityManager securityManager;
> *  private Boolean isIntegratedSecurity;
> *  private boolean isClientAuthenticator; // is there a 
> SECURITY_CLIENT_AUTHENTICATOR
> * private boolean isPeerAuthenticator; // is there a 
> SECURITY_PEER_AUTHENTICATOR
> This could manifest as thread visibility bugs (other thread does not see the 
> value set by another thread).



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

[GitHub] geode-native issue #52: GEODE-2513 Rename gfcpp.properties file to geode.pro...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/52
  
Good catch, @karensmolermiller  - corrections incorporated.


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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode-native/pull/52
  
Good catch, @karensmolermiller  - corrections incorporated.


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[GitHub] geode-native pull request #52: GEODE-2513 Rename gfcpp.properties file to ge...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2513:


Commit 013b336aa08abfbcb4a48f27e9601ff3b6ab37cd in geode-native's branch 
refs/heads/develop from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=013b336 ]

GEODE-2513 Rename gfcpp.properties file to geode.properties - updated 
references, moved and renamed files
This closes #52


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[jira] [Commented] (GEODE-2513) Geode Native docs: rebrand to match open-source software

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Geode Native docs: rebrand to match open-source software
> 
>
> Key: GEODE-2513
> URL: https://issues.apache.org/jira/browse/GEODE-2513
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>
> The newly-contributed Geode Native doc sources contain some GemFire artifacts 
> that have been purged from the open-source code. Docs should be updated to 
> match. 



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

[jira] [Commented] (GEODE-2651) Function service should provide built-in mechanism for streaming back large function results

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-2651:
--

Geode does support streaming results using ResultSender.addResult within the 
function and using a custom result collector when executing a function.

However, geode does provide any sort of back pressure for this stream, so it's 
possible that streaming back a large amount of data could still result in 
running out of memory. 

> Function service should provide built-in mechanism for streaming back large 
> function results
> 
>
> Key: GEODE-2651
> URL: https://issues.apache.org/jira/browse/GEODE-2651
> Project: Geode
>  Issue Type: Improvement
>  Components: functions
>Reporter: Jared Stewart
>
> It would be convenient to have a built-in mechanism for streaming back large 
> function results that does not require keeping all results in memory on 
> either end of the function execution.  Example use cases: 
> - Executing a function to gather all logs on server (this may produce a very 
> large zip file)
> - Executing netstat -lsof currently runs out of memory in CI



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

[jira] [Reopened] (GEODE-2548) Hang in PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults

[nabarun (JIRA)]

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

nabarun reopened GEODE-2548:


> Hang in 
> PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults
> ---
>
> Key: GEODE-2548
> URL: https://issues.apache.org/jira/browse/GEODE-2548
> Project: Geode
>  Issue Type: Test
>  Components: lucene
>Reporter: Jason Huynh
>
> There is possibly a race condition in starting/stopping the caches with 
> persistent regions.
> It appears to hang with this in the logs:
> [vm0] [info 2017/02/24 16:44:56.609 PST  AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE> tid=0x49] Region 
> /region (and any colocated sub-regions) has potentially stale data.  Buckets 
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] are waiting for another offline member to 
> recover the latest data.
> [vm0] My persistent id is:
> [vm0]   DiskStore ID: 110901a3-8e42-4d25-a1ee-4ead6f966a29
> [vm0]   Name: 
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm0/.
> [vm0] Offline members with potentially new data:
> [vm0] [
> [vm0]   DiskStore ID: 582f64c5-d53b-463c-a6a5-b4a0bea79381
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm1/.
> [vm0]   Buckets: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> [vm0] ]
> [vm0] Use the "gfsh show missing-disk-stores" command to see all disk stores 
> that are being waited on by other members.
> [vm0] 19.470: [GC (Allocation Failure) [PSYoungGen: 72510K->9170K(76288K)] 
> 76117K->12784K(251392K), 0.0057840 secs] [Times: user=0.02 sys=0.00, 
> real=0.00 secs] 
> [vm0] [warn 2017/02/24 16:45:03.778 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:45:33.783 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:46:03.786 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:03.791 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:33.794 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:03.796 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:33.799 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:03.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:33.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:50:03.804 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks



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

[jira] [Resolved] (GEODE-2548) Hang in PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults

[nabarun (JIRA)]

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

nabarun resolved GEODE-2548.

   Resolution: Not A Bug
Fix Version/s: 1.2.0

> Hang in 
> PaginationDUnitTest.alternativelyCloseDataStoresAfterGettingAPageAndThenValidateTheContentsOfTheResults
> ---
>
> Key: GEODE-2548
> URL: https://issues.apache.org/jira/browse/GEODE-2548
> Project: Geode
>  Issue Type: Test
>  Components: lucene
>Reporter: Jason Huynh
> Fix For: 1.2.0
>
>
> There is possibly a race condition in starting/stopping the caches with 
> persistent regions.
> It appears to hang with this in the logs:
> [vm0] [info 2017/02/24 16:44:56.609 PST  AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE> tid=0x49] Region 
> /region (and any colocated sub-regions) has potentially stale data.  Buckets 
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] are waiting for another offline member to 
> recover the latest data.
> [vm0] My persistent id is:
> [vm0]   DiskStore ID: 110901a3-8e42-4d25-a1ee-4ead6f966a29
> [vm0]   Name: 
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm0/.
> [vm0] Offline members with potentially new data:
> [vm0] [
> [vm0]   DiskStore ID: 582f64c5-d53b-463c-a6a5-b4a0bea79381
> [vm0]   Location: 
> /192.168.1.84:/Users/jhuynh/Pivotal/gemfire/scorpion/open/geode-lucene/dunit/vm1/.
> [vm0]   Buckets: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
> [vm0] ]
> [vm0] Use the "gfsh show missing-disk-stores" command to see all disk stores 
> that are being waited on by other members.
> [vm0] 19.470: [GC (Allocation Failure) [PSYoungGen: 72510K->9170K(76288K)] 
> 76117K->12784K(251392K), 0.0057840 secs] [Times: user=0.02 sys=0.00, 
> real=0.00 secs] 
> [vm0] [warn 2017/02/24 16:45:03.778 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:45:33.783 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:46:03.786 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:03.791 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:47:33.794 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:03.796 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:48:33.799 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:03.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:49:33.802 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks
> [vm0] [warn 2017/02/24 16:50:03.804 PST  
> tid=0x43] Persistent data recovery for region /region is prevented by offline 
> colocated regions
> [vm0] /index#_region.files
> [vm0] /AsyncEventQueue_index#_region_PARALLEL_GATEWAY_SENDER_QUEUE
> [vm0] /index#_region.chunks



--
This message was sent by Atlassian JIRA
(v6.3.1

[jira] [Commented] (GEODE-2645) Refactor CacheLogRollDUnitTest to be an IntegrationTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2645:


Commit 4a247484a481784065354a170306dc52b0a4133d in geode's branch 
refs/heads/feature/GEODE-2645 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=4a24748 ]

GEODE-2645: rewrite test to fix flakiness and improve readability


> Refactor CacheLogRollDUnitTest to be an IntegrationTest
> ---
>
> Key: GEODE-2645
> URL: https://issues.apache.org/jira/browse/GEODE-2645
> Project: Geode
>  Issue Type: Wish
>  Components: logging, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> CacheLogRollDUnitTest appears to only use one JVM so it should be ported from 
> using DUnit to being a more simple IntegrationTest.
> It also has 4 flaky test bugs:
> * GEODE-674
> * GEODE-675
> * GEODE-676
> * GEODE-677
> If possible, test cleanup should also try to resolve the flakiness in these 
> tests.



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

"rat" task hangs on Windows

[Bruce Schuchardt]

The "rat" task has started hanging on my Windows 7 machine.  I've run 
with & without the gradle daemon and get the same result. With debug 
output it periodically logs this:


14:53:55.907 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] 
DaemonExpirationPeriodicCheck running
14:53:55.908 [DEBUG] 
[org.gradle.launcher.daemon.server.health.DaemonStatus] GC rate: 0.0/s
14:53:55.911 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] 
Waiting to acquire shared lock on daemon addresses registry.
14:53:55.912 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] 
Lock acquired.
14:53:55.913 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] 
Releasing lock on daemon addresses registry.

[jira] [Resolved] (GEODE-2594) Remove optional usage of Attach API

[Kirk Lund (JIRA)]

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

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

> Remove optional usage of Attach API
> ---
>
> Key: GEODE-2594
> URL: https://issues.apache.org/jira/browse/GEODE-2594
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, gfsh
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: StartCommand, StatusCommand, StopCommand, gfsh
> Fix For: 1.2.0
>
>
> This is a request to remove our optional usage of Attach API.
> Users keep running into issues caused by GFSH using the Attach API. If the 
> user kills a GemFire process that was started by GFSH, the Attach API leaves 
> a java_pid file in /tmp which prevents the Attach API from working with any 
> future JVMs that reuse that pid. Most users also want to use a JRE without 
> the tools.jar.
> The only functionality that will be removed is status and stop command 
> support for --pid option.



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

Re: "rat" task hangs on Windows

[Dan Smith]

I've seen this happen before (on linux) if you have very large files in
your workspace that rat is trying to analyze. Unfortunately, rat is not
just looking at files tracked by git but any files that are in your
checkout directory and aren't excluded in gradle/rat.gradle.

So maybe check to see if you have any large files lying around in your
checkout?

-Dan

On Mon, Mar 13, 2017 at 2:55 PM, Bruce Schuchardt 
wrote:

> The "rat" task has started hanging on my Windows 7 machine.  I've run with
> & without the gradle daemon and get the same result. With debug output it
> periodically logs this:
>
> 14:53:55.907 [DEBUG] [org.gradle.launcher.daemon.server.Daemon]
> DaemonExpirationPeriodicCheck running
> 14:53:55.908 [DEBUG] [org.gradle.launcher.daemon.server.health.DaemonStatus]
> GC rate: 0.0/s
> 14:53:55.911 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager]
> Waiting to acquire shared lock on daemon addresses registry.
> 14:53:55.912 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager]
> Lock acquired.
> 14:53:55.913 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager]
> Releasing lock on daemon addresses registry.
>
>
>

[jira] [Commented] (GEODE-2633) When turning on fine logging, GEODE logs the keystore password in clear text

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2633:


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

GEODE-2633: When turning on fine logging, GEODE logs the keystore password in 
clear text
  * spotless fix


> When turning on fine logging, GEODE logs the keystore password in clear text
> 
>
> Key: GEODE-2633
> URL: https://issues.apache.org/jira/browse/GEODE-2633
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, logging
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.2.0
>
>
> When turning on fine logging GEODE logs the keystore password in clear text.



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

[jira] [Commented] (GEODE-2645) Refactor CacheLogRollDUnitTest to be an IntegrationTest

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2645:


Commit a9435d644b042e37d5ffa0fb0c63eddb39e40c1b in geode's branch 
refs/heads/feature/GEODE-2645 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a9435d6 ]

GEODE-2645: rewrite test to fix flakiness and improve readability


> Refactor CacheLogRollDUnitTest to be an IntegrationTest
> ---
>
> Key: GEODE-2645
> URL: https://issues.apache.org/jira/browse/GEODE-2645
> Project: Geode
>  Issue Type: Wish
>  Components: logging, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> CacheLogRollDUnitTest appears to only use one JVM so it should be ported from 
> using DUnit to being a more simple IntegrationTest.
> It also has 4 flaky test bugs:
> * GEODE-674
> * GEODE-675
> * GEODE-676
> * GEODE-677
> If possible, test cleanup should also try to resolve the flakiness in these 
> tests.



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