Re: Review Request 54617: GEODE-2196: add more tests to cover import cluster-configuration and deploy

[Kevin Duling]

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


Ship it!




Ship It!

- Kevin Duling


On Dec. 12, 2016, 12:13 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54617/
> ---
> 
> (Updated Dec. 12, 2016, 12:13 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Kevin Duling, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2196: add more tests to cover import cluster-configuration and deploy
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java
>  5eb070dd99be6d4a8f710341001879f424d7183c 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfigImpl.java
>  0c6603dba932ff8c23312e422d677e8650e0cb17 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/SharedConfiguration.java
>  a45e84362f411ff2908dd6b1a8978a0d9eb8df43 
>   geode-core/src/main/java/org/apache/geode/internal/JarDeployer.java 
> f6a6e8ebf1a130a799f36b1b041162769c787ec5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ImportSharedConfigurationArtifactsFunction.java
>  883a0360559e13a946579660d7e4cc81a94d8841 
>   
> geode-core/src/test/java/org/apache/geode/management/ConnectToLocatorSSLDUnitTest.java
>  142ce17a144547168f7ee89fecc6caf35665296d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/ClusterConfigDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/DeployCommandsSecurityTest.java
>  b040751e0c9b93560aae7d69726c627094978740 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/DistributedRestoreSystemProperties.java
>  221b52a714d9df1106edb40f26f8b542283ca735 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
>  74909284ccb07cc9ed582b7e7423c107c29dbfde 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/rules/LocatorServerStartupRule.java
>  c56f7abbba7382fbd2542596e8337c5a83280d47 
>   
> geode-core/src/test/resources/org/apache/geode/management/internal/configuration/cluster_config.zip
>  37cacbf82a6fcdf284a61c78178a02e6ef20e632 
> 
> Diff: https://reviews.apache.org/r/54617/diff/
> 
> 
> Testing
> ---
> 
> -- added tests for import cluster config and deploy jars
> -- refactor the GfshConnectorRule to do the retry logic inside the rule so 
> that users won't have worry about it.
> -- moved all the expected data/verification code into ClusterConfigResult 
> class to make the main test class cleaner.
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Build failed in Jenkins: Geode-nightly #684

[Apache Jenkins Server]

See 

Changes:

[dbarnes] Removed a misplaced occurrence of "Pivotal" from the docs.

[klund] GEODE-2204: apply FlakyTest category to flaky test

[klund] GEODE-1027: add unit test for previously committed fix

[klund] GEODE-1334: add FlakyTest category to flaky test

[klund] GEODE-1333: add FlakyTest category to flaky test

[klund] GEODE-209: disable broken test until race condition is fixed

[klund] GEODE-1977: add FlakyTest category to flaky test

[klund] GEODE-1975: add FlakyTest category to flaky test

[klund] GEODE-1974: add FlakyTest category to flaky test

[klund] GEODE-2099: reduce scope of method and vars to prevent spaghetti

--
[...truncated 545 lines...]
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse: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:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan: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-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input f

Nightly build #684

[Kirk Lund]

I don't know what's causing these failures... looks like Gradle. Do we know
if the problem is Gradle or the Apache build machines?

:geode-core:integrationTestUnexpected exception thrown.
org.gradle.internal.remote.internal.MessageIOException: Could not read
message from '/127.0.0.1:46897'.
at
org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:85)
at
org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:250)
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.IllegalArgumentException
at
org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:71)
at
org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
at
org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:78)
... 6 more
org.gradle.internal.remote.internal.ConnectException: Could not connect to
server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
[/0:0:0:0:0:0:0:1, /127.0.0.1].
at
org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:66)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedClient.getConnection(MessageHubBackedClient.java:35)
at
org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
at
org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:45)
at
worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:61)
at
worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:66)
Caused by: java.net.ConnectException: Connection refused
at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
at
org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.tryConnect(TcpOutgoingConnector.java:80)
at
org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:53)
... 5 more
 FAILED

Re: Build failed in Jenkins: Geode-nightly #684

[Jinmei Liao]

Do we know why the last two builds failed with "'Gradle Test Executor 1801'
finished with non-zero exit value 1" this error message? There are no test
failures anymore.

On Tue, Dec 13, 2016 at 9:17 AM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> Changes:
>
> [dbarnes] Removed a misplaced occurrence of "Pivotal" from the docs.
>
> [klund] GEODE-2204: apply FlakyTest category to flaky test
>
> [klund] GEODE-1027: add unit test for previously committed fix
>
> [klund] GEODE-1334: add FlakyTest category to flaky test
>
> [klund] GEODE-1333: add FlakyTest category to flaky test
>
> [klund] GEODE-209: disable broken test until race condition is fixed
>
> [klund] GEODE-1977: add FlakyTest category to flaky test
>
> [klund] GEODE-1975: add FlakyTest category to flaky test
>
> [klund] GEODE-1974: add FlakyTest category to flaky test
>
> [klund] GEODE-2099: reduce scope of method and vars to prevent spaghetti
>
> --
> [...truncated 545 lines...]
> :geode-cq:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-cq:processTestResources
> :geode-cq:testClasses
> :geode-cq:checkMissedTests
> :geode-cq:spotlessJavaCheck
> :geode-cq:spotlessCheck
> :geode-cq:test
> :geode-cq:check
> :geode-cq:build
> :geode-cq:distributedTest
> :geode-cq:flakyTest
> :geode-cq:integrationTest
> :geode-json:assemble
> :geode-json:compileTestJava UP-TO-DATE
> :geode-json:processTestResources UP-TO-DATE
> :geode-json:testClasses UP-TO-DATE
> :geode-json:checkMissedTests UP-TO-DATE
> :geode-json:spotlessJavaCheck
> :geode-json:spotlessCheck
> :geode-json:test UP-TO-DATE
> :geode-json:check
> :geode-json:build
> :geode-json:distributedTest UP-TO-DATE
> :geode-json:flakyTest UP-TO-DATE
> :geode-json:integrationTest UP-TO-DATE
> :geode-junit:javadoc
> :geode-junit:javadocJar
> :geode-junit:sourcesJar
> :geode-junit:signArchives SKIPPED
> :geode-junit:assemble
> :geode-junit:compileTestJava
> :geode-junit:processTestResources UP-TO-DATE
> :geode-junit:testClasses
> :geode-junit:checkMissedTests
> :geode-junit:spotlessJavaCheck
> :geode-junit:spotlessCheck
> :geode-junit:test
> :geode-junit:check
> :geode-junit:build
> :geode-junit:distributedTest
> :geode-junit:flakyTest
> :geode-junit:integrationTest
> :geode-lucene:assemble
> :geode-lucene:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-lucene:processTestResources
> :geode-lucene:testClasses
> :geode-lucene:checkMissedTests
> :geode-lucene:spotlessJavaCheck
> :geode-lucene:spotlessCheck
> :geode-lucene:test
> :geode-lucene:check
> :geode-lucene:build
> :geode-lucene:distributedTest
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources UP-TO-DATE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-pulse:assemble
> :geode-pulse:compileTestJavaNote:  job/Geode-nightly/ws/geode-pulse/src/test/java/org/
> apache/geode/tools/pulse/tests/ui/PulseBase.java> uses or overrides a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-pulse: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:check
> :geode-rebalancer:build
> :geode-rebalancer:distributedTest
> :geode-rebalancer:flakyTest
> :geode-rebalancer:integrationTest
> :geode-wan:assemble
> :geode-wan:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input

[jira] [Created] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

Karen Smoler Miller created GEODE-2208:
--

 Summary: Document limitation of transactions on mixed region types
 Key: GEODE-2208
 URL: https://issues.apache.org/jira/browse/GEODE-2208
 Project: Geode
  Issue Type: Improvement
  Components: docs
Reporter: Karen Smoler Miller
Assignee: Mark Bretl


For transactions that run on a mix of replicated and partitioned regions, the 
first operation needs to be to a partitioned region.  This sets/fixes the host 
where subsequent operations will run, and it will be where data is colocated if 
there are multiple partitioned regions involved. If the first operation is to 
the replicated region, then the host set may be one that is not where the 
colocated data is, leading to data not colocated exceptions.

This limitation needs to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-2208:
--

Assignee: Karen Smoler Miller  (was: Mark Bretl)

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller commented on GEODE-2208:


Since I'm already touching the section on transactions, I'm also going to fix a 
minor issue with the navigation links. The two subsections "About Transactions" 
and "Types of Transactions" are in the same file, and the subnav does not 
handle this case well.  So, I will collapse the 2 subsections into 1.

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2128) geode-modules-tomcat8 distributedTests use default cacher server port 40404 and may fail with BindExceptions

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-2128:
-
Labels: CI Flaky  (was: CI)

> geode-modules-tomcat8 distributedTests use default cacher server port 40404 
> and may fail with BindExceptions
> 
>
> Key: GEODE-2128
> URL: https://issues.apache.org/jira/browse/GEODE-2128
> Project: Geode
>  Issue Type: Bug
>  Components: http session, tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>  Labels: CI, Flaky
>
> {noformat}
> :extensions/geode-modules-tomcat8:distributedTest
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > 
> testBasicRegion FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest$$Lambda$12/1474055482.call
>  in VM 1 running on Host 789c68bb5631 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:282)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.setupServer(Tomcat8SessionsClientServerDUnitTest.java:61)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.postSetUp(Tomcat8SessionsClientServerDUnitTest.java:45)
> Caused by:
> java.net.BindException: Failed to create server socket on  
> null[40,404]
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:744)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:711)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:436)
> at 
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:318)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.lambda$setupServer$f0fd67c5$1(Tomcat8SessionsClientServerDUnitTest.java:66)
> 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)
> ... 5 more
> java.lang.NullPointerException
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.preTearDown(Tomcat8SessionsClientServerDUnitTest.java:53)
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest > 
> testCommitSessionValveInvalidSession FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest$$Lambda$12/1474055482.call
>  in VM 1 running on Host 789c68bb5631 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:344)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:314)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:282)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.setupServer(Tomcat8SessionsClientServerDUnitTest.java:61)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.postSetUp(Tomcat8SessionsClientServerDUnitTest.java:45)
> Caused by:
> java.net.BindException: Failed to create server socket on  
> null[40,404]
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:782)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:744)
> at 
> org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:711)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.(AcceptorImpl.java:436)
> at 
> org.apache.geode.internal.cache.CacheServerImpl.start(CacheServerImpl.java:318)
> at 
> org.apache.geode.modules.session.Tomcat8SessionsClientServerDUnitTest.lambda$setupServer$f0fd67c5$1(Tomcat8SessionsClientServerDUnitTest.java:66)
> 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(ServerSoc

Review Request 54713: GEODE-105: Adding a test for creating an index with null map values

[Jason Huynh]

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

Review request for geode, nabarun nag and Dan Smith.


Repository: geode


Description
---

Adding a test to make sure an NPE is not thrown while creating a map index when 
a value present in the region with a map value is null.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
 988defb 

Diff: https://reviews.apache.org/r/54713/diff/


Testing
---


Thanks,

Jason Huynh

[jira] [Closed] (GEODE-1716) Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest of the tests to fail.

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1716.


> Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest 
> of the tests to fail.
> ---
>
> Key: GEODE-1716
> URL: https://issues.apache.org/jira/browse/GEODE-1716
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Udo Kohlmeyer
>Priority: Minor
>
> In JMXMBeanDUnitTest the testJMXOverNonSSL test is causing the whole test 
> class to fail. It seems the RMI stuff does not clean up nicely after itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1716) Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest of the tests to fail.

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1716.
--
Resolution: Not A Problem

Looks like JMXMBeanDUnitTest (including testJMXOverNonSSL) was successfully 
merged to develop and is passing.

> Non-ssl RMI server seems not to be cleaning up after itself. Causing the rest 
> of the tests to fail.
> ---
>
> Key: GEODE-1716
> URL: https://issues.apache.org/jira/browse/GEODE-1716
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Udo Kohlmeyer
>Priority: Minor
>
> In JMXMBeanDUnitTest the testJMXOverNonSSL test is causing the whole test 
> class to fail. It seems the RMI stuff does not clean up nicely after itself.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54713: GEODE-105: Adding a test for creating an index with null map values

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Dec. 13, 2016, 6:41 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54713/
> ---
> 
> (Updated Dec. 13, 2016, 6:41 p.m.)
> 
> 
> Review request for geode, nabarun nag and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding a test to make sure an NPE is not thrown while creating a map index 
> when a value present in the region with a map value is null.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
>  988defb 
> 
> Diff: https://reviews.apache.org/r/54713/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: [DRAFT] Geode Board Report for December 2016

[Dan Smith]

Updated draft below with feedback from Mark and Anthony incorporated.

-Dan


## Description:
 - Apache Geode provides a database-like consistency model, reliable
   transaction processing and a shared-nothing architecture to maintain
   very low latency performance with high concurrency.

## Issues:
 - No issues requiring board attention at this time

## Activity:
 - Graduated from the incubator November 21, 2016!
 - Released our first non-milestone release, 1.0.0-incubating.
 - Transitioned project resources from incubator to TLP namespace.
 - Started discussions about our first release as a TLP.
 - Jinmei Liao presented a talk at apachecon Europe: "Implementing
Security in Apache Geode Using Apache Shiro."

## Health report:
 - Geode is still seeing active development. With our first
non-milestone release we're hoping to settle into a more regular
release cadence. We're still working to attract more contributors from
outside of Pivotal and since graduation we're seeing more
contributions coming in from other sources which is a good sign.

## PMC changes:

 - No PMC changes since the last report to the incubator board.

## Committer base changes:

 - Ken Howe joined as a committer Nov 15th.

## Releases:

 - 1.0.0-incubating October 25, 2016
 - 1.0.0-incubating.M3 August 23, 2016
 - 1.0.0-incubating.M2 April 22, 2016
 - 1.0.0-incubating.M1 Feb 8, 2016

## Mailing list activity:

 - dev@geode.apache.org:

- 154 subscribers (down -3 in the last 3 months):
- 2258 emails sent to list (1529 in previous quarter)

 - iss...@geode.apache.org:

- 55 subscribers (up 0 in the last 3 months):
- 2977 emails sent to list (2751 in previous quarter)

 - u...@geode.apache.org:

- 194 subscribers (up 13 in the last 3 months):
- 187 emails sent to list (157 in previous quarter)

## JIRA activity:

 - 320 JIRA tickets created in the last 3 months
 - 279 JIRA tickets closed/resolved in the last 3 months

Re: Review Request 54713: GEODE-105: Adding a test for creating an index with null map values

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Dec. 13, 2016, 6:41 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54713/
> ---
> 
> (Updated Dec. 13, 2016, 6:41 p.m.)
> 
> 
> Review request for geode, nabarun nag and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding a test to make sure an NPE is not thrown while creating a map index 
> when a value present in the region with a map value is null.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
>  988defb 
> 
> Diff: https://reviews.apache.org/r/54713/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

[jira] [Resolved] (GEODE-1715) gfsh ignores socket buffer size and message time to live while starting a server.

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1715.
--
   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

> gfsh ignores socket buffer size and message time to live while starting a 
> server.
> -
>
> Key: GEODE-1715
> URL: https://issues.apache.org/jira/browse/GEODE-1715
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Srikrishan Malik
> Fix For: 1.0.0-incubating
>
>
> These tunables are set in the serverLauncher instance used to create the 
> command line but are not included in the command line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-1715) gfsh ignores socket buffer size and message time to live while starting a server.

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1715.


> gfsh ignores socket buffer size and message time to live while starting a 
> server.
> -
>
> Key: GEODE-1715
> URL: https://issues.apache.org/jira/browse/GEODE-1715
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Srikrishan Malik
> Fix For: 1.0.0-incubating
>
>
> These tunables are set in the serverLauncher instance used to create the 
> command line but are not included in the command line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1536) Poor documentation and misleading error messages with multi user security

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-1536:
--

Part of this bug is duplicated by GEODE-2144.

> Poor documentation and misleading error messages with multi user security
> -
>
> Key: GEODE-1536
> URL: https://issues.apache.org/jira/browse/GEODE-1536
> Project: Geode
>  Issue Type: Bug
>  Components: docs, security
>Reporter: Dan Smith
>  Labels: bug-hunt
>
> I'm trying to connect a client using multi user security authentication.
> I couldn't find any description of how to use this feature in the manuals. 
> The javadocs for ClientCacheFactory.setPoolMultiuserAuthentication basically 
> provide no information. If you just set that, you get this misleading error 
> message:
> {code}
> java.lang.UnsupportedOperationException: Use Pool APIs for doing operations 
> when multiuser-secure-mode-enabled is set to true.
> {code}
> What you actually need to do is call cache.createAuthenticatedView. However, 
> if you just do that, you get this error message
> {code}
> com.gemstone.gemfire.cache.client.ServerOperationException: remote server on 
> 172.16.115.238(73827:loner):60898:2126f43c: 
> com.gemstone.gemfire.security.AuthenticationRequiredException: No security-* 
> properties are provided
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:671)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:772)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:603)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:165)
>   at 
> com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:110)
>   at 
> com.gemstone.gemfire.cache.client.internal.PoolImpl.execute(PoolImpl.java:700)
>   at 
> com.gemstone.gemfire.cache.client.internal.PutOp.execute(PutOp.java:102)
>   at 
> com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:175)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.serverPut(LocalRegion.java:3061)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3188)
>   at 
> com.gemstone.gemfire.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:230)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5845)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:132)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.basicPut(LocalRegion.java:5240)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1557)
>   at 
> com.gemstone.gemfire.internal.cache.LocalRegion.put(LocalRegion.java:1544)
>   at 
> com.gemstone.gemfire.internal.cache.AbstractRegion.put(AbstractRegion.java:288)
>   at 
> com.gemstone.gemfire.cache.client.internal.ProxyRegion.put(ProxyRegion.java:459)
>   at TestClient.test(TestClient.java:29)
>   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.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.junit.runner.JUnitCore.run(JUnitCore.java:137)
>   at 
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java

[jira] [Resolved] (GEODE-1450) Move ExampleJSONAuthorization out of 'test' and into 'main'

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1450.
--
Resolution: Fixed

> Move ExampleJSONAuthorization out of 'test' and into 'main'
> ---
>
> Key: GEODE-1450
> URL: https://issues.apache.org/jira/browse/GEODE-1450
> Project: Geode
>  Issue Type: Task
>  Components: security
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>  Labels: Example
> Fix For: 1.0.0-incubating
>
>
> Adding a wiki page and I'd like to be able to reference this class as an 
> example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1450) Move ExampleJSONAuthorization out of 'test' and into 'main'

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1450:
-
Fix Version/s: 1.0.0-incubating

> Move ExampleJSONAuthorization out of 'test' and into 'main'
> ---
>
> Key: GEODE-1450
> URL: https://issues.apache.org/jira/browse/GEODE-1450
> Project: Geode
>  Issue Type: Task
>  Components: security
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>  Labels: Example
> Fix For: 1.0.0-incubating
>
>
> Adding a wiki page and I'd like to be able to reference this class as an 
> example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-1450) Move ExampleJSONAuthorization out of 'test' and into 'main'

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1450.


> Move ExampleJSONAuthorization out of 'test' and into 'main'
> ---
>
> Key: GEODE-1450
> URL: https://issues.apache.org/jira/browse/GEODE-1450
> Project: Geode
>  Issue Type: Task
>  Components: security
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>  Labels: Example
> Fix For: 1.0.0-incubating
>
>
> Adding a wiki page and I'd like to be able to reference this class as an 
> example.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Nightly build #684

[Jared Stewart]

I did some poking around on Google and it looks like this exception can be 
thrown by Gradle when a test calls System.exit().  We do have some tests that 
call System.exit(), I wonder if one of them is at fault.

- Jared 

> On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> 
> I don't know what's causing these failures... looks like Gradle. Do we know
> if the problem is Gradle or the Apache build machines?
> 
> :geode-core:integrationTestUnexpected exception thrown.
> org.gradle.internal.remote.internal.MessageIOException: Could not read
> message from '/127.0.0.1:46897'.
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:85)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$ConnectionReceive.run(MessageHub.java:250)
> 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.IllegalArgumentException
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:71)
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$MessageReader.read(InterHubMessageSerializer.java:52)
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(SocketConnection.java:78)
> ... 6 more
> org.gradle.internal.remote.internal.ConnectException: Could not connect to
> server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
> [/0:0:0:0:0:0:0:1, /127.0.0.1].
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:66)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedClient.getConnection(MessageHubBackedClient.java:35)
> at
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:71)
> at
> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWorker.call(SystemApplicationClassLoaderWorker.java:45)
> at
> worker.org.gradle.process.internal.worker.GradleWorkerMain.run(GradleWorkerMain.java:61)
> at
> worker.org.gradle.process.internal.worker.GradleWorkerMain.main(GradleWorkerMain.java:66)
> Caused by: java.net.ConnectException: Connection refused
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.tryConnect(TcpOutgoingConnector.java:80)
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(TcpOutgoingConnector.java:53)
> ... 5 more
> FAILED

[jira] [Resolved] (GEODE-1270) Update spring-security to latest 4.x version

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1270.
--
   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

> Update spring-security to latest 4.x version
> 
>
> Key: GEODE-1270
> URL: https://issues.apache.org/jira/browse/GEODE-1270
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, pulse, rest (admin)
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-1270) Update spring-security to latest 4.x version

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1270.


> Update spring-security to latest 4.x version
> 
>
> Key: GEODE-1270
> URL: https://issues.apache.org/jira/browse/GEODE-1270
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh, pulse, rest (admin)
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1211) Multiple Regions using the same DiskStore cause double-counting in the member TotalDiskUsage JMX attribute

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1211:
-
Component/s: statistics
 persistence

> Multiple Regions using the same DiskStore cause double-counting in the member 
> TotalDiskUsage JMX attribute
> --
>
> Key: GEODE-1211
> URL: https://issues.apache.org/jira/browse/GEODE-1211
> Project: Geode
>  Issue Type: Bug
>  Components: jmx, management, persistence, statistics
>Reporter: Barry Oglesby
>
> Here is what I'm seeing in my simple tests.
> After putting with 1 entries into two persistent replicated regions each 
> using its own disk store:
> {{MemberMBean.getTotalDiskUsage}} totals each disk store bytes on disk 
> properly:
> {noformat}
> MemberMBean.getTotalDiskUsage returning 1298573 bytes
> DiskStoreMBeanBridge.getTotalBytesOnDisk data-rr_store returning 649253 bytes
> DiskStoreMBeanBridge.getTotalBytesOnDisk data2-rr_store returning 649320 bytes
> {noformat}
> After putting with 1 entries into two persistent replicated regions each 
> using the same disk store:
> {{MemberMBean.getTotalDiskUsage}} double-counts the disk store bytes on disk:
> {noformat}
> MemberMBean.getTotalDiskUsage returning 2596956 bytes
> DiskStoreMBeanBridge.getTotalBytesOnDisk data-rr_store returning 1298478 bytes
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1173) NPE thrown from ServerConnection method getPostAuthzRequest()

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-1173.
--
   Resolution: Fixed
Fix Version/s: 1.0.0-incubating

> NPE thrown from ServerConnection method getPostAuthzRequest()
> -
>
> Key: GEODE-1173
> URL: https://issues.apache.org/jira/browse/GEODE-1173
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>
> App log:
> {noformat}
> 2015-11-13 08:47:20,039Z][ERROR][ServerConnection on port 40012 Thread 
> 168272:0xe][functions.server.ServerFunction] Unexpected.
> java.lang.NullPointerException
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.getPostAuthzRequest(ServerConnection.java:2039)
> at 
> com.gemstone.gemfire.internal.cache.execute.ServerToClientFunctionResultSender.authorizeResult(ServerToClientFunctionResultSender.java:251)
> at 
> com.gemstone.gemfire.internal.cache.execute.ServerToClientFunctionResultSender65.lastResult(ServerToClientFunctionResultSender65.java:58)
> at 
> com.tradingscreen.toolbox.gemfire.functions.server.ServerFunction.execute(ServerFunction.java:202)
> at 
> com.tradingscreen.toolbox.gemfire.functions.server.ServerFunction.execute(ServerFunction.java:283)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction66.executeFunctionaLocally(ExecuteFunction66.java:324)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction66.cmdExecute(ExecuteFunction66.java:247)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction70.cmdExecute(ExecuteFunction70.java:51)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:182)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:789)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:920)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:579)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> GF log:
> {noformat}
> [warn 2015/11/13 03:47:20.038 EST  10.0.0.4(kfleikman@pazit-PC@1447345441780@1.25.6@7.0.2.27:loner):20138:8d9783fc:kfleikman@pazit-PC@1447345441780@1.25.6@7.0.2.27
>  (kfleikman@pazit-PC@1.25.6@7.0.2.27_gem_Amoeba)> tid=0xe] 
> CacheClientProxy[identity(10.0.0.4(kfleikman@pazit-PC@1447398026079@1.25.6@7.0.2.27:loner):1209:0485a6ff:kfleikman@pazit-PC@1447398026079@1.25.6@7.0.2.27,connection=1,durableAttributes=DurableClientAttributes[id=kfleikman@pazit-PC@1.25.6@7.0.2.27_gem_Amoeba;
>  timeout=345600]); port=52572; primary=true; version=GFE 7.0.1]: Proxy 
> closing due to unexpected broken pipe on socket connection.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-1173) NPE thrown from ServerConnection method getPostAuthzRequest()

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-1173.


> NPE thrown from ServerConnection method getPostAuthzRequest()
> -
>
> Key: GEODE-1173
> URL: https://issues.apache.org/jira/browse/GEODE-1173
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Reporter: Jens Deppe
> Fix For: 1.0.0-incubating
>
>
> App log:
> {noformat}
> 2015-11-13 08:47:20,039Z][ERROR][ServerConnection on port 40012 Thread 
> 168272:0xe][functions.server.ServerFunction] Unexpected.
> java.lang.NullPointerException
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.getPostAuthzRequest(ServerConnection.java:2039)
> at 
> com.gemstone.gemfire.internal.cache.execute.ServerToClientFunctionResultSender.authorizeResult(ServerToClientFunctionResultSender.java:251)
> at 
> com.gemstone.gemfire.internal.cache.execute.ServerToClientFunctionResultSender65.lastResult(ServerToClientFunctionResultSender65.java:58)
> at 
> com.tradingscreen.toolbox.gemfire.functions.server.ServerFunction.execute(ServerFunction.java:202)
> at 
> com.tradingscreen.toolbox.gemfire.functions.server.ServerFunction.execute(ServerFunction.java:283)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction66.executeFunctionaLocally(ExecuteFunction66.java:324)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction66.cmdExecute(ExecuteFunction66.java:247)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.command.ExecuteFunction70.cmdExecute(ExecuteFunction70.java:51)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:182)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:789)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:920)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at 
> com.gemstone.gemfire.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:579)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> GF log:
> {noformat}
> [warn 2015/11/13 03:47:20.038 EST  10.0.0.4(kfleikman@pazit-PC@1447345441780@1.25.6@7.0.2.27:loner):20138:8d9783fc:kfleikman@pazit-PC@1447345441780@1.25.6@7.0.2.27
>  (kfleikman@pazit-PC@1.25.6@7.0.2.27_gem_Amoeba)> tid=0xe] 
> CacheClientProxy[identity(10.0.0.4(kfleikman@pazit-PC@1447398026079@1.25.6@7.0.2.27:loner):1209:0485a6ff:kfleikman@pazit-PC@1447398026079@1.25.6@7.0.2.27,connection=1,durableAttributes=DurableClientAttributes[id=kfleikman@pazit-PC@1.25.6@7.0.2.27_gem_Amoeba;
>  timeout=345600]); port=52572; primary=true; version=GFE 7.0.1]: Proxy 
> closing due to unexpected broken pipe on socket connection.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2144) Improve the error message when a Java client specifies no username/password

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-2144:


Assignee: Jared Stewart

> Improve the error message when a Java client specifies no username/password
> ---
>
> Key: GEODE-2144
> URL: https://issues.apache.org/jira/browse/GEODE-2144
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> If you set up a secured locator/server and attempt to connect via a Java 
> client which does not specify a username/password, the error message is not 
> very helpful:
> {code}
> Message when no security-username and security-password specified is awful: 
> Exception in thread "main" 
> org.apache.geode.security.AuthenticationRequiredException: No security-* 
> properties are provided
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1473)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1327)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:135)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:466)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:312)
> at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:320)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:147)
> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:133)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:319)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2990)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1169)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:746)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:189)
> at com.jaredjstewart.HelloWorld.main(HelloWorld.java:44)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}
> It would be much nicer to tell the user that they need to specify a 
> username/password.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2144) Improve the error message when a Java client specifies no username/password

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2144:
-
Fix Version/s: 1.1.0

> Improve the error message when a Java client specifies no username/password
> ---
>
> Key: GEODE-2144
> URL: https://issues.apache.org/jira/browse/GEODE-2144
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
> Fix For: 1.1.0
>
>
> If you set up a secured locator/server and attempt to connect via a Java 
> client which does not specify a username/password, the error message is not 
> very helpful:
> {code}
> Message when no security-username and security-password specified is awful: 
> Exception in thread "main" 
> org.apache.geode.security.AuthenticationRequiredException: No security-* 
> properties are provided
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1473)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1327)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:135)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:466)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:312)
> at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:320)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:147)
> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:133)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:319)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2990)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1169)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:746)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:189)
> at com.jaredjstewart.HelloWorld.main(HelloWorld.java:44)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}
> It would be much nicer to tell the user that they need to specify a 
> username/password.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-1119) Programmatically creating regions should work with cluster configuration

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1119:
-
Issue Type: Wish  (was: Bug)

> Programmatically creating regions should work with cluster configuration
> 
>
> Key: GEODE-1119
> URL: https://issues.apache.org/jira/browse/GEODE-1119
> Project: Geode
>  Issue Type: Wish
>  Components: configuration
>Reporter: Swapnil Bawaskar
>
> When a region is created Programmatically (using RegionFactory):
> * the region definition is lost when the member re-starts
> * it does not show up in exported cluster configuration
> * the region is not created on other members of the system.
> Creating regions programmatically, should work just like creating region 
> through gfsh; in conjunction with cluster config, so that the region:
> * is created when this member is re-started
> * created on all members of the system without needing Function execution to 
> create regions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1119) Programmatically creating regions should work with cluster configuration

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-1119:
--

Changing this to a Wish. Currently using the API to create a Region is 
considered the way to create a Region without it persisting to the cluster 
configuration. There are arguments both for and against this change.

The CommandService API is the API that is supposed to accept command strings 
(same syntax as you'd enter in GFSH) that would create a region in cluster 
configuration. Unfortunately the CommandService API has not yet been completed, 
but there are peer-to-peer and client-to-server flavors that were specified in 
the CommandService API spec.

> Programmatically creating regions should work with cluster configuration
> 
>
> Key: GEODE-1119
> URL: https://issues.apache.org/jira/browse/GEODE-1119
> Project: Geode
>  Issue Type: Wish
>  Components: configuration
>Reporter: Swapnil Bawaskar
>
> When a region is created Programmatically (using RegionFactory):
> * the region definition is lost when the member re-starts
> * it does not show up in exported cluster configuration
> * the region is not created on other members of the system.
> Creating regions programmatically, should work just like creating region 
> through gfsh; in conjunction with cluster config, so that the region:
> * is created when this member is re-started
> * created on all members of the system without needing Function execution to 
> create regions.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Issue Comment Deleted] (GEODE-1114) Remove sqlfire/GemFireXD references from Pulse

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-1114:
-
Comment: was deleted

(was: Commit 22ca5ef829fee20024d44264b3839ee745916975 in incubator-geode's 
branch refs/heads/feature/GEODE-17-2 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=22ca5ef ]

GEODE-693: refactor security dunit tests

* GEODE-1114: remove com.gemstone.gemfire.internal.util.Callable
* convert security dunit tests to JUnit 4
* use RetryRule on ClientPostAuthorizationDUnitTest.testAllPostOps
* convert public variables and methods to private and/or protected
* convert many static variables and methods to instance
)

> Remove sqlfire/GemFireXD references from Pulse
> --
>
> Key: GEODE-1114
> URL: https://issues.apache.org/jira/browse/GEODE-1114
> Project: Geode
>  Issue Type: Task
>  Components: pulse
>Reporter: Jens Deppe
>
> No need to drag around this old code



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-796) Stand alone Geode Server process did not return query results in gfsh

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-796.
---

> Stand alone Geode Server process did not return query results in gfsh
> -
>
> Key: GEODE-796
> URL: https://issues.apache.org/jira/browse/GEODE-796
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Luke Shannon
>
> I started a single server process with JMX enabled:
> gfsh start server \
>--name=$SERVER_NAME \
>--use-cluster-configuration=false \
>--classpath=$CLASSPATH \
>--server-port=0 \
>--dir=$SERVER_DIR_LOCATION/$SERVER_NAME \
>--J=-Xms1g \
>--J=-Xmx1g \
>--J=-Dgemfire.jmx-manager=true \
>--J=-Dgemfire.jmx-manager-start=true \
>--properties-file=$CONF_DIR/gemfire.properties \
>--spring-xml-location=file:///$CONF_DIR/spring-cache.xml
> I was able to connect to gfsh using the JMX-Manager argument for gfsh 
> connect. When I tried to list the members I got a 'null' back in gfsh. For a 
> query count(*) on a region, the correct right entry count was returned, 
> however select * just returned a 'null'. There were no errors in the server 
> logs. When I did the same config, however this time started a locator (and 
> referenced it in the server start command) I was able to connect using the 
> locator argument of connect. Everything worked as expected this time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-796) Stand alone Geode Server process did not return query results in gfsh

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-796.
-
Resolution: Cannot Reproduce

The description is what would happen if you failed to connect to the Jmx 
Manager from GFSH. There's not enough information here to debug any further. 
When I follow similar steps of what is reported, it works fine.

> Stand alone Geode Server process did not return query results in gfsh
> -
>
> Key: GEODE-796
> URL: https://issues.apache.org/jira/browse/GEODE-796
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Luke Shannon
>
> I started a single server process with JMX enabled:
> gfsh start server \
>--name=$SERVER_NAME \
>--use-cluster-configuration=false \
>--classpath=$CLASSPATH \
>--server-port=0 \
>--dir=$SERVER_DIR_LOCATION/$SERVER_NAME \
>--J=-Xms1g \
>--J=-Xmx1g \
>--J=-Dgemfire.jmx-manager=true \
>--J=-Dgemfire.jmx-manager-start=true \
>--properties-file=$CONF_DIR/gemfire.properties \
>--spring-xml-location=file:///$CONF_DIR/spring-cache.xml
> I was able to connect to gfsh using the JMX-Manager argument for gfsh 
> connect. When I tried to list the members I got a 'null' back in gfsh. For a 
> query count(*) on a region, the correct right entry count was returned, 
> however select * just returned a 'null'. There were no errors in the server 
> logs. When I did the same config, however this time started a locator (and 
> referenced it in the server start command) I was able to connect using the 
> locator argument of connect. Everything worked as expected this time.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-790) Update documentation

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-790.
-
Resolution: Incomplete

No actionable information on what needs to be done. Description is empty.

> Update documentation
> 
>
> Key: GEODE-790
> URL: https://issues.apache.org/jira/browse/GEODE-790
> Project: Geode
>  Issue Type: Sub-task
>  Components: pulse, rest (dev)
>Reporter: Jens Deppe
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (GEODE-790) Update documentation

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-790.
---

> Update documentation
> 
>
> Key: GEODE-790
> URL: https://issues.apache.org/jira/browse/GEODE-790
> Project: Geode
>  Issue Type: Sub-task
>  Components: pulse, rest (dev)
>Reporter: Jens Deppe
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-747) Not able to create sub-region from gfsh in the cluster configuration

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-747:
-

This one is potentially contentious. The product management team that defined 
and released GFSH wanted two things: 1) to leave out things like sub-regions 
that they didn't want to encourage users to to use, and 2) to eventually 
deprecated and remove sub-regions altogether.


> Not able to create sub-region from gfsh in the cluster configuration
> 
>
> Key: GEODE-747
> URL: https://issues.apache.org/jira/browse/GEODE-747
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, gfsh
>Reporter: Jens Deppe
>
> Received this from Gemfire forum 
> started a brand new locator and server, then try to create the region as 
> following:
> {noformat}
> create region --name=/a --type=REPLICATE_PERSISTENT 
> create region --name=/a/b --type=REPLICATE_PERSISTENT
> {noformat}
> suppose it will create the parent / child regions, where /b is a sub-region 
> nested in /a.
> But once it's created, I found in 
> $GemFire Work Dir$\locator1\cluster_config\cluster\cluster.xml
> They are two different regions without any parent-child relationship.
> {noformat}
> 
> http://schema.pivotal.io/gemfire/cache 
> ​http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd"; lock-lease="120" 
> lock-timeout="60" search-timeout="300" is-server="false" copy-on-read="false" 
> version="8.1" xmlns="​http://schema.pivotal.io/gemfire/cache"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";>
>   
>  data-policy="persistent-replicate"/>
>   
>   
>  data-policy="persistent-replicate"/>
>   
> 
> {noformat}
> also 
> When I execute 
> {noformat}
> create region --name=/b --type=PARTITION_PERSISTENT
> {noformat}
> it works
> List regions showing below but no change in cluster.xml
> {noformat}
> gfsh>list regions
> List of regions
> a
> a/b
> b
> {noformat}
> Stop and start server getting below value
> {noformat}
> gfsh>stop server --name=cache1
> gfsh>start server --name=cache1 --use-cluster-configuration
> gfsh>list regions
> List of regions
> a
> b
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-742) status locator command return null for output

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-742.
-
Resolution: Won't Fix

This test does not exist in GEODE.

> status locator command return null for output
> -
>
> Key: GEODE-742
> URL: https://issues.apache.org/jira/browse/GEODE-742
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>
> {noformat}
> [info 2015/09/02 10:43:20.802 PDT  
> tid=0x25] runCommand-Executing Command status locator with command Mgr 
> com.gemstone.gemfire.management.internal.cli.CommandManager@31637e79
> [info 2015/09/02 10:43:20.804 PDT  
> tid=0x25] Command 'status locator' took 2 ms
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] execCommand-shell.getCompletorOutput() for status locator={}
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] execCommand-commandOutput for status 
> locator={com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommands.statusLocator=CommandResult
>  [gfJsonObject={"content":{"errorCode":520,"message":["null"]}}, 
> status=ERROR, index=1, isDataBuilt=true, 
> resultData=com.gemstone.gemfire.management.internal.cli.result.ErrorResultData@22a791db,
>  resultLines=[null
>   ], failedToPersist=false]}
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] getPresentationString-Start
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] checkForRightPadding-Start
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] Calling clearEvents() on management.cli.TestableGfsh@38b81a42
> [severe 2015/09/02 10:43:20.807 PDT  
> tid=0x25] Task result: INITTASK[16] 
> management.test.cli.CommandTest.HydraTask_execConnectedCommands: ERROR 
> util.TestException: Unexpected command output:null
>   util.TestException: Unexpected command output:null
> at 
> management.test.cli.CommandTest.checkForFatalErrors(CommandTest.java:6847)
> at management.test.cli.CommandTest.execCommand(CommandTest.java:6614)
> at 
> management.test.cli.CommandTest.checkOutputLines(CommandTest.java:6213)
> at 
> management.test.cli.CommandTest.cmdStatusLocatorTest(CommandTest.java:5875)
> at 
> management.test.cli.CommandTest.HydraTask_execConnectedCommands(CommandTest.java:1002)
> 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 hydra.MethExecutor.execute(MethExecutor.java:189)
> at hydra.MethExecutor.execute(MethExecutor.java:153)
> at hydra.TestTask.execute(TestTask.java:194)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:216)
> {noformat}
> bugreport
> {noformat}
> Host name: w2-2013-lin-24
> OS name: Linux
> Architecture: amd64
> OS version: 2.6.32-220.23.1.el6.x86_64
> Java version: 1.8.0_45
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.8.0_45/x86_64.linux/jre
>   #
>   
>   GemFire Version 9.0.0-SNAPSHOT
>   Source Date: 2015-08-27 10:54:49 -0700
>   Source Revision: 49d99d4e5d97ecc682e9929251ab959ff7307e7a
>   Source Repository: develop
>   
>   Build Id: spillai 083015
>   Build Date: 2015-08-30 23:51:57 -0700
>   Build Version: 9.0.0-SNAPSHOT spillai 083015 2015-08-30 23:51:57 -0700 
> javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 amd64
>   
>   #
> Test was run from 
> /export/w2-2013-lin-01a/users/spillai/gfe/gemfire/closed/gemfire-test/build/resources/test/management/test/cli/cli.bt
> Test:
> management/test/cli/p2pExecCommands.conf
>A=peer
>B=admin
>C=cli
>adminHosts=1
>adminThreadsPerVM=1
>adminVMsPerHost=1
>cliHosts=1
>cliThreadsPerVM=1
>cliVMsPerHost=1
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>numMembersCreateCacheOnly=0
>numMembersJoinDSOnly=0
>peerHosts=4
>peerThreadsPerVM=1
>peerVMsPerHost=1
>redundantCopies=1
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1441215735668;
> *** Test failed with this error:
> CLIENT vm_1_thr_1_cli1_w2-2013-lin-24_10173
> INITTASK[16] management.test.cli.CommandTest.HydraTask_execConnectedCommands
> ERROR util.TestException: Unexpected command output:null
> util.TestException: Unexpected command output:null
>   at 
> management.test.cli.CommandTest.checkForFatalErrors(CommandTest.java:6847)
>   at management.test.cli.CommandTest.execCommand(CommandTest.ja

[jira] [Closed] (GEODE-741) NotificationListener getSource() method does not return useful information

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-741.
---

> NotificationListener getSource() method does not return useful information
> --
>
> Key: GEODE-741
> URL: https://issues.apache.org/jira/browse/GEODE-741
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Reporter: Jens Deppe
>
> {noformat}
> Host name: w2-gst-pnq-01
> OS name: Linux
> Architecture: amd64
> OS version: 2.6.32-220.el6.x86_64
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.7.0_72/x86_64.linux/jre
>   #
>   
>   GemFire Version 9.0.0-SNAPSHOT
>   Source Date: 2015-08-23 21:04:58 -0700
>   Source Revision: eeb7ae1778d6af454526d1daba79422f903b5f06
>   Source Repository: develop
>   
>   Build Id: lynn 082515
>   Build Date: 2015-08-25 15:34:15 -0700
>   Build Version: 9.0.0-SNAPSHOT lynn 082515 2015-08-25 15:34:15 -0700 javac 
> 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.el6.x86_64 amd64
>   
>   #
> Test was run from batt.bt
> Test:
> asyncMsg/concBurst.conf
>A=JMXClient
>B=peer
>JMXClientHosts=1
>JMXClientThreadsPerVM=1
>JMXClientVMsPerHost=1
>hydra.numHosts=5
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>peerHosts=10
>peerThreadsPerVM=5
>peerVMsPerHost=1
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1440543431332;
> This test passed, but logs jmx notifications using a NotificationListener. 
> This listener just logs the information
> in the notification object. The "source" (obtained by calling 
> Notification.getSource()) always logs as
> "DistributedSystem(-1)", which doesn't really give any useful information.
> The java docs say the source is the object on which the event occurred. But 
> the returned string is always the same, 
> no matter which member the event came from. 
> We need have this return useful information. We also need a unit test for 
> this.
> Note that this is a new test and is currently checked in only on branch 
> wip-remove-deprecated.
> [info 2015/08/25 16:08:20.739 PDT  tid=0x15] Invoked 
> util.NotificationLogListener. in JMXClient1
> notification: 
> javax.management.Notification[source=DistributedSystem(-1)][type=system.alert][message=15
>  seconds have elapsed while waiting for replies: 
>  replies from 
> [w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-pnq-01_11311:11311):56168]> on 
> w2-gst-pnq-01(peergemfire3_w2-gst-pnq-01_11380:11380):48369 whose current 
> membership list is: 
> [[w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(locatorgemfire1_w2-gst-pnq-01_11306:11306):2275, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-pnq-01_11311:11311):56168, 
> w2-gst-pnq-01(peergemfire3_w2-gst-pnq-01_11380:11380):48369]]]
> source: DistributedSystem(-1)
> handback: null
> timestamp: 1440544100736
> sequence number: 489
> type: system.alert
> message: 15 seconds have elapsed while waiting for replies: 
>  replies from 
> [w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-pnq-01_11311:11311):56168]> on 
> w2-gst-pnq-01(peergemfire3_w2-gs

[jira] [Resolved] (GEODE-741) NotificationListener getSource() method does not return useful information

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-741.
-
Resolution: Won't Fix

This test does not exist in GEODE.

> NotificationListener getSource() method does not return useful information
> --
>
> Key: GEODE-741
> URL: https://issues.apache.org/jira/browse/GEODE-741
> Project: Geode
>  Issue Type: Improvement
>  Components: jmx
>Reporter: Jens Deppe
>
> {noformat}
> Host name: w2-gst-pnq-01
> OS name: Linux
> Architecture: amd64
> OS version: 2.6.32-220.el6.x86_64
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.7.0_72/x86_64.linux/jre
>   #
>   
>   GemFire Version 9.0.0-SNAPSHOT
>   Source Date: 2015-08-23 21:04:58 -0700
>   Source Revision: eeb7ae1778d6af454526d1daba79422f903b5f06
>   Source Repository: develop
>   
>   Build Id: lynn 082515
>   Build Date: 2015-08-25 15:34:15 -0700
>   Build Version: 9.0.0-SNAPSHOT lynn 082515 2015-08-25 15:34:15 -0700 javac 
> 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.el6.x86_64 amd64
>   
>   #
> Test was run from batt.bt
> Test:
> asyncMsg/concBurst.conf
>A=JMXClient
>B=peer
>JMXClientHosts=1
>JMXClientThreadsPerVM=1
>JMXClientVMsPerHost=1
>hydra.numHosts=5
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>peerHosts=10
>peerThreadsPerVM=5
>peerVMsPerHost=1
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1440543431332;
> This test passed, but logs jmx notifications using a NotificationListener. 
> This listener just logs the information
> in the notification object. The "source" (obtained by calling 
> Notification.getSource()) always logs as
> "DistributedSystem(-1)", which doesn't really give any useful information.
> The java docs say the source is the object on which the event occurred. But 
> the returned string is always the same, 
> no matter which member the event came from. 
> We need have this return useful information. We also need a unit test for 
> this.
> Note that this is a new test and is currently checked in only on branch 
> wip-remove-deprecated.
> [info 2015/08/25 16:08:20.739 PDT  tid=0x15] Invoked 
> util.NotificationLogListener. in JMXClient1
> notification: 
> javax.management.Notification[source=DistributedSystem(-1)][type=system.alert][message=15
>  seconds have elapsed while waiting for replies: 
>  replies from 
> [w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-pnq-01_11311:11311):56168]> on 
> w2-gst-pnq-01(peergemfire3_w2-gst-pnq-01_11380:11380):48369 whose current 
> membership list is: 
> [[w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(locatorgemfire1_w2-gst-pnq-01_11306:11306):2275, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-pnq-01_11311:11311):56168, 
> w2-gst-pnq-01(peergemfire3_w2-gst-pnq-01_11380:11380):48369]]]
> source: DistributedSystem(-1)
> handback: null
> timestamp: 1440544100736
> sequence number: 489
> type: system.alert
> message: 15 seconds have elapsed while waiting for replies: 
>  replies from 
> [w2-gst-pnq-01(peergemfire8_w2-gst-pnq-01_11510:11510):32066, 
> w2-gst-pnq-01(peergemfire9_w2-gst-pnq-01_11537:11537):38847, 
> w2-gst-pnq-01(peergemfire7_w2-gst-pnq-01_11488:11488):55130, 
> w2-gst-pnq-01(peergemfire2_w2-gst-pnq-01_11357:11357):56822, 
> w2-gst-pnq-01(peergemfire10_w2-gst-pnq-01_11334:11334):59949, 
> w2-gst-pnq-01(peergemfire4_w2-gst-pnq-01_11408:11408):10401, 
> w2-gst-pnq-01(peergemfire6_w2-gst-pnq-01_11460:11460):7746, 
> w2-gst-pnq-01(peergemfire5_w2-gst-pnq-01_11432:11432):8911, 
> w2-gst-pnq-01(peergemfire1_w2-gst-

[jira] [Closed] (GEODE-742) status locator command return null for output

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-742.
---

> status locator command return null for output
> -
>
> Key: GEODE-742
> URL: https://issues.apache.org/jira/browse/GEODE-742
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kirk Lund
>
> {noformat}
> [info 2015/09/02 10:43:20.802 PDT  
> tid=0x25] runCommand-Executing Command status locator with command Mgr 
> com.gemstone.gemfire.management.internal.cli.CommandManager@31637e79
> [info 2015/09/02 10:43:20.804 PDT  
> tid=0x25] Command 'status locator' took 2 ms
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] execCommand-shell.getCompletorOutput() for status locator={}
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] execCommand-commandOutput for status 
> locator={com.gemstone.gemfire.management.internal.cli.commands.LauncherLifecycleCommands.statusLocator=CommandResult
>  [gfJsonObject={"content":{"errorCode":520,"message":["null"]}}, 
> status=ERROR, index=1, isDataBuilt=true, 
> resultData=com.gemstone.gemfire.management.internal.cli.result.ErrorResultData@22a791db,
>  resultLines=[null
>   ], failedToPersist=false]}
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] getPresentationString-Start
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] checkForRightPadding-Start
> [info 2015/09/02 10:43:20.805 PDT  
> tid=0x25] Calling clearEvents() on management.cli.TestableGfsh@38b81a42
> [severe 2015/09/02 10:43:20.807 PDT  
> tid=0x25] Task result: INITTASK[16] 
> management.test.cli.CommandTest.HydraTask_execConnectedCommands: ERROR 
> util.TestException: Unexpected command output:null
>   util.TestException: Unexpected command output:null
> at 
> management.test.cli.CommandTest.checkForFatalErrors(CommandTest.java:6847)
> at management.test.cli.CommandTest.execCommand(CommandTest.java:6614)
> at 
> management.test.cli.CommandTest.checkOutputLines(CommandTest.java:6213)
> at 
> management.test.cli.CommandTest.cmdStatusLocatorTest(CommandTest.java:5875)
> at 
> management.test.cli.CommandTest.HydraTask_execConnectedCommands(CommandTest.java:1002)
> 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 hydra.MethExecutor.execute(MethExecutor.java:189)
> at hydra.MethExecutor.execute(MethExecutor.java:153)
> at hydra.TestTask.execute(TestTask.java:194)
> at hydra.RemoteTestModule$1.run(RemoteTestModule.java:216)
> {noformat}
> bugreport
> {noformat}
> Host name: w2-2013-lin-24
> OS name: Linux
> Architecture: amd64
> OS version: 2.6.32-220.23.1.el6.x86_64
> Java version: 1.8.0_45
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.8.0_45/x86_64.linux/jre
>   #
>   
>   GemFire Version 9.0.0-SNAPSHOT
>   Source Date: 2015-08-27 10:54:49 -0700
>   Source Revision: 49d99d4e5d97ecc682e9929251ab959ff7307e7a
>   Source Repository: develop
>   
>   Build Id: spillai 083015
>   Build Date: 2015-08-30 23:51:57 -0700
>   Build Version: 9.0.0-SNAPSHOT spillai 083015 2015-08-30 23:51:57 -0700 
> javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 amd64
>   
>   #
> Test was run from 
> /export/w2-2013-lin-01a/users/spillai/gfe/gemfire/closed/gemfire-test/build/resources/test/management/test/cli/cli.bt
> Test:
> management/test/cli/p2pExecCommands.conf
>A=peer
>B=admin
>C=cli
>adminHosts=1
>adminThreadsPerVM=1
>adminVMsPerHost=1
>cliHosts=1
>cliThreadsPerVM=1
>cliVMsPerHost=1
>locatorHosts=1
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>numMembersCreateCacheOnly=0
>numMembersJoinDSOnly=0
>peerHosts=4
>peerThreadsPerVM=1
>peerVMsPerHost=1
>redundantCopies=1
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1441215735668;
> *** Test failed with this error:
> CLIENT vm_1_thr_1_cli1_w2-2013-lin-24_10173
> INITTASK[16] management.test.cli.CommandTest.HydraTask_execConnectedCommands
> ERROR util.TestException: Unexpected command output:null
> util.TestException: Unexpected command output:null
>   at 
> management.test.cli.CommandTest.checkForFatalErrors(CommandTest.java:6847)
>   at management.test.cli.CommandTest.execCommand(CommandTest.java:6614)
>   at 
> management.test.cli.CommandTest.checkOutput

[jira] [Closed] (GEODE-740) JMX ClientIds returns info for killed client (which should not be included in the list of ClientIds)

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-740.
---

> JMX ClientIds returns info for killed client (which should not be included in 
> the list of ClientIds)
> 
>
> Key: GEODE-740
> URL: https://issues.apache.org/jira/browse/GEODE-740
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Jens Deppe
>
> I think this bug is initially about ensuring that we have a test which checks 
> that the clientIDs reported by the management framework is accurate when 
> clients are killed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-740) JMX ClientIds returns info for killed client (which should not be included in the list of ClientIds)

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-740.
-
Resolution: Won't Fix

Test does not exist in GEODE.

> JMX ClientIds returns info for killed client (which should not be included in 
> the list of ClientIds)
> 
>
> Key: GEODE-740
> URL: https://issues.apache.org/jira/browse/GEODE-740
> Project: Geode
>  Issue Type: Bug
>  Components: jmx
>Reporter: Jens Deppe
>
> I think this bug is initially about ensuring that we have a test which checks 
> that the clientIDs reported by the management framework is accurate when 
> clients are killed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-738) DEFAULT diskstore is missing in some members in cluster config tests

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-738.
-
Resolution: Won't Fix

Test does not exist in GEODE.

> DEFAULT diskstore is missing in some members in cluster config tests
> 
>
> Key: GEODE-738
> URL: https://issues.apache.org/jira/browse/GEODE-738
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Jens Deppe
>
> This is observed in 8.1 regression.
> {noformat}
> Host name: w1-gst-dev04
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-123.el7.x86_64
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.7.0_72/x86_64.linux/jre
>   #
>   
>   GemFire Version 8.1.0.6
>   Source Date: Fri, 22 May 2015 10:39:59 -0700
>   
>   Source Revision: 6aa105334252e99556c4a01c70abacdb20fc033b
>   Source Repository: gemfire810X_maint
>   
>   Build Id: build 052215
>   Build Date: 05/22/2015 11:09:03 PDT
>   Build Version: 8.1.0.6 build 052215 05/22/2015 11:09:03 PDT javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 i386
>   
>   #
> Test was run from 
> /export/snaps/gfe/81/Linux/snapshots.052215/gf810XMaintsancout/tests/classes/management/clusterconfig/clusterConfig.bt
> Test:
> management/clusterconfig/serialCacheRegionEntryGroupOpsRecycleVM.conf
>A=dataStoreGroup1
>B=dataStoreGroup2
>C=cli
>cliHosts=2
>cliThreadsPerVM=1
>cliVMsPerHost=1
>dataStoreGroup1Hosts=3
>dataStoreGroup1ThreadsPerVM=1
>dataStoreGroup1VMsPerHost=1
>dataStoreGroup2Hosts=3
>dataStoreGroup2ThreadsPerVM=1
>dataStoreGroup2VMsPerHost=1
>locatorHosts=2
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>numDataStoreMembersToHostRegion=0
>numMembersCreateCacheOnly=6
>numMembersJoinDSOnly=0
>redundantCopies=2
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1432324011057;
> *** Test failed with this error:
> CLIENT vm_3_thr_3_dataStoreGroup12_w1-gst-dev04_19748
> CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot
> ERROR util.TestException: Expected to find diskStores [DEFAULT] defined in 
> cache
> util.TestException: Expected to find diskStores [DEFAULT] defined in cache
>   at 
> management.clusterconfig.ClusterConfigTest.verifyDiskStoreSnapshot(ClusterConfigTest.java:421)
>   at 
> management.clusterconfig.ClusterConfigTest.verifySnapshot(ClusterConfigTest.java:316)
>   at 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot(ClusterConfigTest.java:292)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at hydra.MethExecutor.execute(MethExecutor.java:189)
>   at hydra.MethExecutor.execute(MethExecutor.java:153)
>   at hydra.TestTask.execute(TestTask.java:194)
>   at hydra.RemoteTestModule$1.run(RemoteTestModule.java:217)
> The test has two group of clusters as given below.
> group1 : vm_2, vm_3, vm_4
> group2 : vm_5, vm_6, vm_7
> *** vm_4 from group1 has written the snapshot, written the diskstore to bb 
> which contains "DEFAULT" diskstore
> [info 2015/05/22 12:50:32.387 PDT 
>  tid=0xdb] Received task: 
> CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot
> [info 2015/05/22 12:50:32.391 PDT 
>  tid=0xdb] Waiting for a 
> period of silence for 60 seconds...
> [info 2015/05/22 12:51:32.439 PDT 
>  tid=0xdb] Done waiting, 
> clients have been silent for 60048 ms
> [info 2015/05/22 12:51:32.451 PDT 
>  tid=0xdb] Writing following 
> senders in snapshot:
> [info 2015/05/22 12:51:32.456 PDT 
>  tid=0xdb] After writing 
> following senders exist in snapshot:
> [info 2015/05/22 12:51:32.456 PDT 
>  tid=0xdb] Writing following 
> receivers in snapshot:
> [info 2015/05/22 12:51:32.457 PDT 
>  tid=0xdb] After writing 
> following recievers exist in snapshot:
> *** vm_2 and vm_3 compared their diskstore with snapshot (writen by vm_4) and 
> reported missing "DEFAULT" diskstore
> dataStoreGroup1Gemfire1/vm_2_dataStoreGroup11_w1-gst-dev04_18209.log:[severe 
> 2015/05/22 12:51:34.473 PDT  
> tid=0xc7] Task result: CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot: ERROR 
> util.TestException: Expected to find diskStores [DEFAULT] defined in cache
> dataStoreGroup1Gemfire1/vm_2_dataStoreGroup1

[jira] [Closed] (GEODE-738) DEFAULT diskstore is missing in some members in cluster config tests

[Kirk Lund (JIRA)]

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

Kirk Lund closed GEODE-738.
---

> DEFAULT diskstore is missing in some members in cluster config tests
> 
>
> Key: GEODE-738
> URL: https://issues.apache.org/jira/browse/GEODE-738
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Jens Deppe
>
> This is observed in 8.1 regression.
> {noformat}
> Host name: w1-gst-dev04
> OS name: Linux
> Architecture: amd64
> OS version: 3.10.0-123.el7.x86_64
> Java version: 1.7.0_72
> Java vm name: Java HotSpot(TM) 64-Bit Server VM
> Java vendor: Oracle Corporation
> Java home: /export/gcm/where/jdk/1.7.0_72/x86_64.linux/jre
>   #
>   
>   GemFire Version 8.1.0.6
>   Source Date: Fri, 22 May 2015 10:39:59 -0700
>   
>   Source Revision: 6aa105334252e99556c4a01c70abacdb20fc033b
>   Source Repository: gemfire810X_maint
>   
>   Build Id: build 052215
>   Build Date: 05/22/2015 11:09:03 PDT
>   Build Version: 8.1.0.6 build 052215 05/22/2015 11:09:03 PDT javac 1.7.0_72
>   Build JDK: Java 1.7.0_72
>   Build Platform: Linux 2.6.32-220.23.1.el6.x86_64 i386
>   
>   #
> Test was run from 
> /export/snaps/gfe/81/Linux/snapshots.052215/gf810XMaintsancout/tests/classes/management/clusterconfig/clusterConfig.bt
> Test:
> management/clusterconfig/serialCacheRegionEntryGroupOpsRecycleVM.conf
>A=dataStoreGroup1
>B=dataStoreGroup2
>C=cli
>cliHosts=2
>cliThreadsPerVM=1
>cliVMsPerHost=1
>dataStoreGroup1Hosts=3
>dataStoreGroup1ThreadsPerVM=1
>dataStoreGroup1VMsPerHost=1
>dataStoreGroup2Hosts=3
>dataStoreGroup2ThreadsPerVM=1
>dataStoreGroup2VMsPerHost=1
>locatorHosts=2
>locatorThreadsPerVM=1
>locatorVMsPerHost=1
>numDataStoreMembersToHostRegion=0
>numMembersCreateCacheOnly=6
>numMembersJoinDSOnly=0
>redundantCopies=2
> No local.conf for this run
> //randomSeed extracted from test:
> hydra.Prms-randomSeed=1432324011057;
> *** Test failed with this error:
> CLIENT vm_3_thr_3_dataStoreGroup12_w1-gst-dev04_19748
> CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot
> ERROR util.TestException: Expected to find diskStores [DEFAULT] defined in 
> cache
> util.TestException: Expected to find diskStores [DEFAULT] defined in cache
>   at 
> management.clusterconfig.ClusterConfigTest.verifyDiskStoreSnapshot(ClusterConfigTest.java:421)
>   at 
> management.clusterconfig.ClusterConfigTest.verifySnapshot(ClusterConfigTest.java:316)
>   at 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot(ClusterConfigTest.java:292)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:606)
>   at hydra.MethExecutor.execute(MethExecutor.java:189)
>   at hydra.MethExecutor.execute(MethExecutor.java:153)
>   at hydra.TestTask.execute(TestTask.java:194)
>   at hydra.RemoteTestModule$1.run(RemoteTestModule.java:217)
> The test has two group of clusters as given below.
> group1 : vm_2, vm_3, vm_4
> group2 : vm_5, vm_6, vm_7
> *** vm_4 from group1 has written the snapshot, written the diskstore to bb 
> which contains "DEFAULT" diskstore
> [info 2015/05/22 12:50:32.387 PDT 
>  tid=0xdb] Received task: 
> CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot
> [info 2015/05/22 12:50:32.391 PDT 
>  tid=0xdb] Waiting for a 
> period of silence for 60 seconds...
> [info 2015/05/22 12:51:32.439 PDT 
>  tid=0xdb] Done waiting, 
> clients have been silent for 60048 ms
> [info 2015/05/22 12:51:32.451 PDT 
>  tid=0xdb] Writing following 
> senders in snapshot:
> [info 2015/05/22 12:51:32.456 PDT 
>  tid=0xdb] After writing 
> following senders exist in snapshot:
> [info 2015/05/22 12:51:32.456 PDT 
>  tid=0xdb] Writing following 
> receivers in snapshot:
> [info 2015/05/22 12:51:32.457 PDT 
>  tid=0xdb] After writing 
> following recievers exist in snapshot:
> *** vm_2 and vm_3 compared their diskstore with snapshot (writen by vm_4) and 
> reported missing "DEFAULT" diskstore
> dataStoreGroup1Gemfire1/vm_2_dataStoreGroup11_w1-gst-dev04_18209.log:[severe 
> 2015/05/22 12:51:34.473 PDT  
> tid=0xc7] Task result: CLOSETASK[0] 
> management.clusterconfig.ClusterConfigTest.HydraTask_verifySnapshot: ERROR 
> util.TestException: Expected to find diskStores [DEFAULT] defined in cache
> dataStoreGroup1Gemfire1/vm_2_dataStoreGroup11_w1-gst-dev04_18209.log:  
> util.TestException: Expected to

[jira] [Resolved] (GEODE-734) gfsh export stack-traces should not require an output file with extension .txt

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-734.
-
   Resolution: Fixed
Fix Version/s: 1.1.0

> gfsh export stack-traces should not require an output file with extension .txt
> --
>
> Key: GEODE-734
> URL: https://issues.apache.org/jira/browse/GEODE-734
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jens Deppe
> Fix For: 1.1.0
>
>
> gfsh {{export stack-traces}} requires a file with a {{.txt}} extension:
> {noformat}
> gfsh>export stack-traces --file=/tmp/trace.log
> Invalid file type, the file extension must be ".txt"
> {noformat}
> This seems like a totally arbitrary restriction. Please can it be removed.
> If the concern is that an existing file might be overwritten then we should 
> have a user prompt indicating that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Nightly build #684

[Kirk Lund]

I tried grepping for "System.exit()" but the only java file I could find is
SystemAdmin.java which is an old command-line class.

Which tests did you find calling exit?


On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart  wrote:

> I did some poking around on Google and it looks like this exception can be
> thrown by Gradle when a test calls System.exit().  We do have some tests
> that call System.exit(), I wonder if one of them is at fault.
>
> - Jared
>
> > On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> >
> > I don't know what's causing these failures... looks like Gradle. Do we
> know
> > if the problem is Gradle or the Apache build machines?
> >
> > :geode-core:integrationTestUnexpected exception thrown.
> > org.gradle.internal.remote.internal.MessageIOException: Could not read
> > message from '/127.0.0.1:46897'.
> > at
> > org.gradle.internal.remote.internal.inet.SocketConnection.receive(
> SocketConnection.java:85)
> > at
> > org.gradle.internal.remote.internal.hub.MessageHub$
> ConnectionReceive.run(MessageHub.java:250)
> > 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.IllegalArgumentException
> > at
> > org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
> MessageReader.read(InterHubMessageSerializer.java:71)
> > at
> > org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
> MessageReader.read(InterHubMessageSerializer.java:52)
> > at
> > org.gradle.internal.remote.internal.inet.SocketConnection.receive(
> SocketConnection.java:78)
> > ... 6 more
> > org.gradle.internal.remote.internal.ConnectException: Could not connect
> to
> > server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
> > addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
> > [/0:0:0:0:0:0:0:1, /127.0.0.1].
> > at
> > org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
> TcpOutgoingConnector.java:66)
> > at
> > org.gradle.internal.remote.internal.hub.MessageHubBackedClient.
> getConnection(MessageHubBackedClient.java:35)
> > at
> > org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWo
> rker.call(SystemApplicationClassLoaderWorker.java:71)
> > at
> > org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWo
> rker.call(SystemApplicationClassLoaderWorker.java:45)
> > at
> > worker.org.gradle.process.internal.worker.GradleWorkerMain.run(
> GradleWorkerMain.java:61)
> > at
> > worker.org.gradle.process.internal.worker.GradleWorkerMain.main(
> GradleWorkerMain.java:66)
> > Caused by: java.net.ConnectException: Connection refused
> > at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> > at sun.nio.ch.SocketChannelImpl.finishConnect(
> SocketChannelImpl.java:717)
> > at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> > at
> > org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.
> tryConnect(TcpOutgoingConnector.java:80)
> > at
> > org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
> TcpOutgoingConnector.java:53)
> > ... 5 more
> > FAILED
>
>

Re: Nightly build #684

[Jared Stewart]

These are all of the files I found within src/test:

ChildVM.java
CompiledClass.java
DistributedSystemConnectPerf.java
GemfireSequenceDisplay.java
LocatorLauncherRemoteIntegrationTest.java
ServerLauncherRemoteIntegrationTest.java
TestXACacheLoader.java
WANBootStrapping_Site1_Add.java
WANBootStrapping_Site1_Remove.java
WANBootStrapping_Site2_Add.java
WANBootStrapping_Site2_Remove.java

> On Dec 13, 2016, at 11:32 AM, Kirk Lund  wrote:
> 
> I tried grepping for "System.exit()" but the only java file I could find is
> SystemAdmin.java which is an old command-line class.
> 
> Which tests did you find calling exit?
> 
> 
> On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart  wrote:
> 
>> I did some poking around on Google and it looks like this exception can be
>> thrown by Gradle when a test calls System.exit().  We do have some tests
>> that call System.exit(), I wonder if one of them is at fault.
>> 
>> - Jared
>> 
>>> On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
>>> 
>>> I don't know what's causing these failures... looks like Gradle. Do we
>> know
>>> if the problem is Gradle or the Apache build machines?
>>> 
>>> :geode-core:integrationTestUnexpected exception thrown.
>>> org.gradle.internal.remote.internal.MessageIOException: Could not read
>>> message from '/127.0.0.1:46897'.
>>> at
>>> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
>> SocketConnection.java:85)
>>> at
>>> org.gradle.internal.remote.internal.hub.MessageHub$
>> ConnectionReceive.run(MessageHub.java:250)
>>> 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.IllegalArgumentException
>>> at
>>> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
>> MessageReader.read(InterHubMessageSerializer.java:71)
>>> at
>>> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
>> MessageReader.read(InterHubMessageSerializer.java:52)
>>> at
>>> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
>> SocketConnection.java:78)
>>> ... 6 more
>>> org.gradle.internal.remote.internal.ConnectException: Could not connect
>> to
>>> server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
>>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
>>> [/0:0:0:0:0:0:0:1, /127.0.0.1].
>>> at
>>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
>> TcpOutgoingConnector.java:66)
>>> at
>>> org.gradle.internal.remote.internal.hub.MessageHubBackedClient.
>> getConnection(MessageHubBackedClient.java:35)
>>> at
>>> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWo
>> rker.call(SystemApplicationClassLoaderWorker.java:71)
>>> at
>>> org.gradle.process.internal.worker.child.SystemApplicationClassLoaderWo
>> rker.call(SystemApplicationClassLoaderWorker.java:45)
>>> at
>>> worker.org.gradle.process.internal.worker.GradleWorkerMain.run(
>> GradleWorkerMain.java:61)
>>> at
>>> worker.org.gradle.process.internal.worker.GradleWorkerMain.main(
>> GradleWorkerMain.java:66)
>>> Caused by: java.net.ConnectException: Connection refused
>>> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>>> at sun.nio.ch.SocketChannelImpl.finishConnect(
>> SocketChannelImpl.java:717)
>>> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
>>> at
>>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.
>> tryConnect(TcpOutgoingConnector.java:80)
>>> at
>>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
>> TcpOutgoingConnector.java:53)
>>> ... 5 more
>>> FAILED
>> 
>> 

[jira] [Updated] (GEODE-536) Remove i18n code

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-536:

Component/s: (was: management)
 logging
 docs

> Remove i18n code
> 
>
> Key: GEODE-536
> URL: https://issues.apache.org/jira/browse/GEODE-536
> Project: Geode
>  Issue Type: Task
>  Components: docs, logging
>Reporter: Roman Shtykh
>Priority: Minor
>
> i18n is not needed. No plans to support it so far.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Nightly build #684

[Kirk Lund]

Ah, I only grepped for System.exit() but these all have an argument. Thanks!

ChildVM, LocatorLauncherRemoteIntegrationTest,
ServerLauncherRemoteIntegrationTest are closing forked JVMs.

CompiledClass, DistributedSystemConnectPerf, GemfireSequenceDisplay all have a
main with calls to exit. These wouldn't be invoked by a test.

TestXACacheLoader, WANBootStrapping_Site1_Add,
WANBootStrapping_Site1_Remove, WANBootStrapping_Site2_Add,
WANBootStrapping_Site2_Remove all have a main as well but they appear to be
completed unused classes that can be deleted.

There doesn't seem to be any JUnit tests that call exit except the launcher
tests. Also, I would expect to find a new test calling exit since this is a
new problem with our nightly build.


On Tue, Dec 13, 2016 at 11:35 AM, Jared Stewart  wrote:

> These are all of the files I found within src/test:
>
> ChildVM.java
> CompiledClass.java
> DistributedSystemConnectPerf.java
> GemfireSequenceDisplay.java
> LocatorLauncherRemoteIntegrationTest.java
> ServerLauncherRemoteIntegrationTest.java
> TestXACacheLoader.java
> WANBootStrapping_Site1_Add.java
> WANBootStrapping_Site1_Remove.java
> WANBootStrapping_Site2_Add.java
> WANBootStrapping_Site2_Remove.java
>
> > On Dec 13, 2016, at 11:32 AM, Kirk Lund  wrote:
> >
> > I tried grepping for "System.exit()" but the only java file I could find
> is
> > SystemAdmin.java which is an old command-line class.
> >
> > Which tests did you find calling exit?
> >
> >
> > On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart 
> wrote:
> >
> >> I did some poking around on Google and it looks like this exception can
> be
> >> thrown by Gradle when a test calls System.exit().  We do have some tests
> >> that call System.exit(), I wonder if one of them is at fault.
> >>
> >> - Jared
> >>
> >>> On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> >>>
> >>> I don't know what's causing these failures... looks like Gradle. Do we
> >> know
> >>> if the problem is Gradle or the Apache build machines?
> >>>
> >>> :geode-core:integrationTestUnexpected exception thrown.
> >>> org.gradle.internal.remote.internal.MessageIOException: Could not read
> >>> message from '/127.0.0.1:46897'.
> >>> at
> >>> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
> >> SocketConnection.java:85)
> >>> at
> >>> org.gradle.internal.remote.internal.hub.MessageHub$
> >> ConnectionReceive.run(MessageHub.java:250)
> >>> 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.IllegalArgumentException
> >>> at
> >>> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
> >> MessageReader.read(InterHubMessageSerializer.java:71)
> >>> at
> >>> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
> >> MessageReader.read(InterHubMessageSerializer.java:52)
> >>> at
> >>> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
> >> SocketConnection.java:78)
> >>> ... 6 more
> >>> org.gradle.internal.remote.internal.ConnectException: Could not
> connect
> >> to
> >>> server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
> >>> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
> >>> [/0:0:0:0:0:0:0:1, /127.0.0.1].
> >>> at
> >>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
> >> TcpOutgoingConnector.java:66)
> >>> at
> >>> org.gradle.internal.remote.internal.hub.MessageHubBackedClient.
> >> getConnection(MessageHubBackedClient.java:35)
> >>> at
> >>> org.gradle.process.internal.worker.child.
> SystemApplicationClassLoaderWo
> >> rker.call(SystemApplicationClassLoaderWorker.java:71)
> >>> at
> >>> org.gradle.process.internal.worker.child.
> SystemApplicationClassLoaderWo
> >> rker.call(SystemApplicationClassLoaderWorker.java:45)
> >>> at
> >>> worker.org.gradle.process.internal.worker.GradleWorkerMain.run(
> >> GradleWorkerMain.java:61)
> >>> at
> >>> worker.org.gradle.process.internal.worker.GradleWorkerMain.main(
> >> GradleWorkerMain.java:66)
> >>> Caused by: java.net.ConnectException: Connection refused
> >>> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> >>> at sun.nio.ch.SocketChannelImpl.finishConnect(
> >> SocketChannelImpl.java:717)
> >>> at sun.nio.ch.SocketAdaptor.connect(SocketAdaptor.java:111)
> >>> at
> >>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.
> >> tryConnect(TcpOutgoingConnector.java:80)
> >>> at
> >>> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
> >> TcpOutgoingConnector.java:53)
> >>> ... 5 more
> >>> FAILED
> >>
> >>
>
>

Re: Nightly build #684

[Jared Stewart]

The other problem I saw that can lead to this error message is the JVM running 
out of memory.  But I don’t know why either of these problems would have just 
started now. 
Here the discussions I found that look to concern the same issue:

[1] 
http://stackoverflow.com/questions/23523831/gradle-build-fail-process-gradle-test-executor-1-finished-with-non-zero-exit
 

[2] 
https://discuss.gradle.org/t/strange-exception-thrown-running-unit-tests/2515/15
 

[3] 
https://discuss.gradle.org/t/unexpected-exception-thrown-org-gradle-messaging-remote-internal-messageioexception-could-not-read-message-from-0/1095
 


- Jared

> On Dec 13, 2016, at 11:46 AM, Kirk Lund  wrote:
> 
> Ah, I only grepped for System.exit() but these all have an argument. Thanks!
> 
> ChildVM, LocatorLauncherRemoteIntegrationTest,
> ServerLauncherRemoteIntegrationTest are closing forked JVMs.
> 
> CompiledClass, DistributedSystemConnectPerf, GemfireSequenceDisplay all have a
> main with calls to exit. These wouldn't be invoked by a test.
> 
> TestXACacheLoader, WANBootStrapping_Site1_Add,
> WANBootStrapping_Site1_Remove, WANBootStrapping_Site2_Add,
> WANBootStrapping_Site2_Remove all have a main as well but they appear to be
> completed unused classes that can be deleted.
> 
> There doesn't seem to be any JUnit tests that call exit except the launcher
> tests. Also, I would expect to find a new test calling exit since this is a
> new problem with our nightly build.
> 
> 
> On Tue, Dec 13, 2016 at 11:35 AM, Jared Stewart  wrote:
> 
>> These are all of the files I found within src/test:
>> 
>> ChildVM.java
>> CompiledClass.java
>> DistributedSystemConnectPerf.java
>> GemfireSequenceDisplay.java
>> LocatorLauncherRemoteIntegrationTest.java
>> ServerLauncherRemoteIntegrationTest.java
>> TestXACacheLoader.java
>> WANBootStrapping_Site1_Add.java
>> WANBootStrapping_Site1_Remove.java
>> WANBootStrapping_Site2_Add.java
>> WANBootStrapping_Site2_Remove.java
>> 
>>> On Dec 13, 2016, at 11:32 AM, Kirk Lund  wrote:
>>> 
>>> I tried grepping for "System.exit()" but the only java file I could find
>> is
>>> SystemAdmin.java which is an old command-line class.
>>> 
>>> Which tests did you find calling exit?
>>> 
>>> 
>>> On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart 
>> wrote:
>>> 
 I did some poking around on Google and it looks like this exception can
>> be
 thrown by Gradle when a test calls System.exit().  We do have some tests
 that call System.exit(), I wonder if one of them is at fault.
 
 - Jared
 
> On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> 
> I don't know what's causing these failures... looks like Gradle. Do we
 know
> if the problem is Gradle or the Apache build machines?
> 
> :geode-core:integrationTestUnexpected exception thrown.
> org.gradle.internal.remote.internal.MessageIOException: Could not read
> message from '/127.0.0.1:46897'.
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
 SocketConnection.java:85)
> at
> org.gradle.internal.remote.internal.hub.MessageHub$
 ConnectionReceive.run(MessageHub.java:250)
> 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.IllegalArgumentException
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
 MessageReader.read(InterHubMessageSerializer.java:71)
> at
> org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
 MessageReader.read(InterHubMessageSerializer.java:52)
> at
> org.gradle.internal.remote.internal.inet.SocketConnection.receive(
 SocketConnection.java:78)
> ... 6 more
> org.gradle.internal.remote.internal.ConnectException: Could not
>> connect
 to
> server [324ba98c-8390-4910-98fc-0ba81e170929 port:49771,
> addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]]. Tried addresses:
> [/0:0:0:0:0:0:0:1, /127.0.0.1].
> at
> org.gradle.internal.remote.internal.inet.TcpOutgoingConnector.connect(
 TcpOutgoingConnector.java:66)
> at
> org.gradle.internal.remote.internal.hub.MessageHubBackedClient.
 getConnection(MessageHubBackedClient.java:35)
> at
> org.gradle.process.internal

Re: Nightly build #684

[Kirk Lund]

Looks like our nightly build has finally gone over 12 hours the past two
nights. I believe all Apache builds that run that long are auto killed.
What can we do to shrink that down? Separate UnitTests, IntegrationTests
and DistributedTests into their own nightly build jobs? Anything else?


On Tue, Dec 13, 2016 at 11:55 AM, Jared Stewart  wrote:

> The other problem I saw that can lead to this error message is the JVM
> running out of memory.  But I don’t know why either of these problems would
> have just started now.
> Here the discussions I found that look to concern the same issue:
>
> [1] http://stackoverflow.com/questions/23523831/gradle-
> build-fail-process-gradle-test-executor-1-finished-with-non-zero-exit <
> http://stackoverflow.com/questions/23523831/gradle-
> build-fail-process-gradle-test-executor-1-finished-with-non-zero-exit>
> [2] https://discuss.gradle.org/t/strange-exception-thrown-
> running-unit-tests/2515/15  strange-exception-thrown-running-unit-tests/2515/15>
> [3] https://discuss.gradle.org/t/unexpected-exception-thrown-
> org-gradle-messaging-remote-internal-messageioexception-
> could-not-read-message-from-0/1095  unexpected-exception-thrown-org-gradle-messaging-remote-
> internal-messageioexception-could-not-read-message-from-0/1095>
>
> - Jared
>
> > On Dec 13, 2016, at 11:46 AM, Kirk Lund  wrote:
> >
> > Ah, I only grepped for System.exit() but these all have an argument.
> Thanks!
> >
> > ChildVM, LocatorLauncherRemoteIntegrationTest,
> > ServerLauncherRemoteIntegrationTest are closing forked JVMs.
> >
> > CompiledClass, DistributedSystemConnectPerf, GemfireSequenceDisplay all
> have a
> > main with calls to exit. These wouldn't be invoked by a test.
> >
> > TestXACacheLoader, WANBootStrapping_Site1_Add,
> > WANBootStrapping_Site1_Remove, WANBootStrapping_Site2_Add,
> > WANBootStrapping_Site2_Remove all have a main as well but they appear to
> be
> > completed unused classes that can be deleted.
> >
> > There doesn't seem to be any JUnit tests that call exit except the
> launcher
> > tests. Also, I would expect to find a new test calling exit since this
> is a
> > new problem with our nightly build.
> >
> >
> > On Tue, Dec 13, 2016 at 11:35 AM, Jared Stewart 
> wrote:
> >
> >> These are all of the files I found within src/test:
> >>
> >> ChildVM.java
> >> CompiledClass.java
> >> DistributedSystemConnectPerf.java
> >> GemfireSequenceDisplay.java
> >> LocatorLauncherRemoteIntegrationTest.java
> >> ServerLauncherRemoteIntegrationTest.java
> >> TestXACacheLoader.java
> >> WANBootStrapping_Site1_Add.java
> >> WANBootStrapping_Site1_Remove.java
> >> WANBootStrapping_Site2_Add.java
> >> WANBootStrapping_Site2_Remove.java
> >>
> >>> On Dec 13, 2016, at 11:32 AM, Kirk Lund  wrote:
> >>>
> >>> I tried grepping for "System.exit()" but the only java file I could
> find
> >> is
> >>> SystemAdmin.java which is an old command-line class.
> >>>
> >>> Which tests did you find calling exit?
> >>>
> >>>
> >>> On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart 
> >> wrote:
> >>>
>  I did some poking around on Google and it looks like this exception
> can
> >> be
>  thrown by Gradle when a test calls System.exit().  We do have some
> tests
>  that call System.exit(), I wonder if one of them is at fault.
> 
>  - Jared
> 
> > On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> >
> > I don't know what's causing these failures... looks like Gradle. Do
> we
>  know
> > if the problem is Gradle or the Apache build machines?
> >
> > :geode-core:integrationTestUnexpected exception thrown.
> > org.gradle.internal.remote.internal.MessageIOException: Could not
> read
> > message from '/127.0.0.1:46897'.
> > at
> > org.gradle.internal.remote.internal.inet.SocketConnection.receive(
>  SocketConnection.java:85)
> > at
> > org.gradle.internal.remote.internal.hub.MessageHub$
>  ConnectionReceive.run(MessageHub.java:250)
> > 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.IllegalArgumentException
> > at
> > org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
>  MessageReader.read(InterHubMessageSerializer.java:71)
> > at
> > org.gradle.internal.remote.internal.hub.InterHubMessageSerializer$
>  MessageReader.read(InterHubMessageSerializer.java:52)
> > at
> > org.gradle.internal.remote.internal.inet.SocketConnection.receive(
>  SocketConnection.j

Re: Nightly build #684

[Anilkumar Gingade]

If its related to time taken by the tests, it may get addressed by breaking
down...But if there is issue with the test, we will still continue to see
it.

-Anil.


On Tue, Dec 13, 2016 at 12:02 PM, Kirk Lund  wrote:

> Looks like our nightly build has finally gone over 12 hours the past two
> nights. I believe all Apache builds that run that long are auto killed.
> What can we do to shrink that down? Separate UnitTests, IntegrationTests
> and DistributedTests into their own nightly build jobs? Anything else?
>
>
> On Tue, Dec 13, 2016 at 11:55 AM, Jared Stewart 
> wrote:
>
> > The other problem I saw that can lead to this error message is the JVM
> > running out of memory.  But I don’t know why either of these problems
> would
> > have just started now.
> > Here the discussions I found that look to concern the same issue:
> >
> > [1] http://stackoverflow.com/questions/23523831/gradle-
> > build-fail-process-gradle-test-executor-1-finished-with-non-zero-exit <
> > http://stackoverflow.com/questions/23523831/gradle-
> > build-fail-process-gradle-test-executor-1-finished-with-non-zero-exit>
> > [2] https://discuss.gradle.org/t/strange-exception-thrown-
> > running-unit-tests/2515/15  > strange-exception-thrown-running-unit-tests/2515/15>
> > [3] https://discuss.gradle.org/t/unexpected-exception-thrown-
> > org-gradle-messaging-remote-internal-messageioexception-
> > could-not-read-message-from-0/1095  > unexpected-exception-thrown-org-gradle-messaging-remote-
> > internal-messageioexception-could-not-read-message-from-0/1095>
> >
> > - Jared
> >
> > > On Dec 13, 2016, at 11:46 AM, Kirk Lund  wrote:
> > >
> > > Ah, I only grepped for System.exit() but these all have an argument.
> > Thanks!
> > >
> > > ChildVM, LocatorLauncherRemoteIntegrationTest,
> > > ServerLauncherRemoteIntegrationTest are closing forked JVMs.
> > >
> > > CompiledClass, DistributedSystemConnectPerf, GemfireSequenceDisplay all
> > have a
> > > main with calls to exit. These wouldn't be invoked by a test.
> > >
> > > TestXACacheLoader, WANBootStrapping_Site1_Add,
> > > WANBootStrapping_Site1_Remove, WANBootStrapping_Site2_Add,
> > > WANBootStrapping_Site2_Remove all have a main as well but they appear
> to
> > be
> > > completed unused classes that can be deleted.
> > >
> > > There doesn't seem to be any JUnit tests that call exit except the
> > launcher
> > > tests. Also, I would expect to find a new test calling exit since this
> > is a
> > > new problem with our nightly build.
> > >
> > >
> > > On Tue, Dec 13, 2016 at 11:35 AM, Jared Stewart 
> > wrote:
> > >
> > >> These are all of the files I found within src/test:
> > >>
> > >> ChildVM.java
> > >> CompiledClass.java
> > >> DistributedSystemConnectPerf.java
> > >> GemfireSequenceDisplay.java
> > >> LocatorLauncherRemoteIntegrationTest.java
> > >> ServerLauncherRemoteIntegrationTest.java
> > >> TestXACacheLoader.java
> > >> WANBootStrapping_Site1_Add.java
> > >> WANBootStrapping_Site1_Remove.java
> > >> WANBootStrapping_Site2_Add.java
> > >> WANBootStrapping_Site2_Remove.java
> > >>
> > >>> On Dec 13, 2016, at 11:32 AM, Kirk Lund  wrote:
> > >>>
> > >>> I tried grepping for "System.exit()" but the only java file I could
> > find
> > >> is
> > >>> SystemAdmin.java which is an old command-line class.
> > >>>
> > >>> Which tests did you find calling exit?
> > >>>
> > >>>
> > >>> On Tue, Dec 13, 2016 at 10:59 AM, Jared Stewart  >
> > >> wrote:
> > >>>
> >  I did some poking around on Google and it looks like this exception
> > can
> > >> be
> >  thrown by Gradle when a test calls System.exit().  We do have some
> > tests
> >  that call System.exit(), I wonder if one of them is at fault.
> > 
> >  - Jared
> > 
> > > On Dec 13, 2016, at 9:36 AM, Kirk Lund  wrote:
> > >
> > > I don't know what's causing these failures... looks like Gradle. Do
> > we
> >  know
> > > if the problem is Gradle or the Apache build machines?
> > >
> > > :geode-core:integrationTestUnexpected exception thrown.
> > > org.gradle.internal.remote.internal.MessageIOException: Could not
> > read
> > > message from '/127.0.0.1:46897'.
> > > at
> > > org.gradle.internal.remote.internal.inet.SocketConnection.receive(
> >  SocketConnection.java:85)
> > > at
> > > org.gradle.internal.remote.internal.hub.MessageHub$
> >  ConnectionReceive.run(MessageHub.java:250)
> > > 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.j

[GitHub] geode pull request #310: [GEODE-2144] Improve error message when no security...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2144) Improve the error message when a Java client specifies no username/password

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> Improve the error message when a Java client specifies no username/password
> ---
>
> Key: GEODE-2144
> URL: https://issues.apache.org/jira/browse/GEODE-2144
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> If you set up a secured locator/server and attempt to connect via a Java 
> client which does not specify a username/password, the error message is not 
> very helpful:
> {code}
> Message when no security-username and security-password specified is awful: 
> Exception in thread "main" 
> org.apache.geode.security.AuthenticationRequiredException: No security-* 
> properties are provided
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1473)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1327)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:135)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:466)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:312)
> at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:320)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:147)
> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:133)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:319)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2990)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1169)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:746)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:189)
> at com.jaredjstewart.HelloWorld.main(HelloWorld.java:44)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}
> It would be much nicer to tell the user that they need to specify a 
> username/password.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2144) Improve the error message when a Java client specifies no username/password

[Kirk Lund (JIRA)]

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

Kirk Lund resolved GEODE-2144.
--
Resolution: Fixed

> Improve the error message when a Java client specifies no username/password
> ---
>
> Key: GEODE-2144
> URL: https://issues.apache.org/jira/browse/GEODE-2144
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jared Stewart
>Assignee: Jared Stewart
> Fix For: 1.1.0
>
>
> If you set up a secured locator/server and attempt to connect via a Java 
> client which does not specify a username/password, the error message is not 
> very helpful:
> {code}
> Message when no security-username and security-password specified is awful: 
> Exception in thread "main" 
> org.apache.geode.security.AuthenticationRequiredException: No security-* 
> properties are provided
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1473)
> at 
> org.apache.geode.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1327)
> at 
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:108)
> at 
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:135)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:466)
> at 
> org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:312)
> at org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:320)
> at 
> org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:147)
> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:133)
> at 
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:319)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2990)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeDeclarativeCache(GemFireCacheImpl.java:1338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1169)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:771)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createClient(GemFireCacheImpl.java:746)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.basicCreate(ClientCacheFactory.java:235)
> at 
> org.apache.geode.cache.client.ClientCacheFactory.create(ClientCacheFactory.java:189)
> at com.jaredjstewart.HelloWorld.main(HelloWorld.java:44)
> 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 com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
> {code}
> It would be much nicer to tell the user that they need to specify a 
> username/password.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54713: GEODE-105: Adding a test for creating an index with null map values

[xiaojian zhou]

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


Ship it!




Ship It!

- xiaojian zhou


On Dec. 13, 2016, 6:41 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54713/
> ---
> 
> (Updated Dec. 13, 2016, 6:41 p.m.)
> 
> 
> Review request for geode, nabarun nag and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding a test to make sure an NPE is not thrown while creating a map index 
> when a value present in the region with a map value is null.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
>  988defb 
> 
> Diff: https://reviews.apache.org/r/54713/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

[jira] [Comment Edited] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller edited comment on GEODE-2208 at 12/13/16 9:42 PM:
--

Since I'm already touching the section on transactions, I'm also going to fix a 
minor issue with the navigation links. The two subsections "About Transactions" 
and "Types of Transactions" are in the same file, and the subnav does not 
handle this case well.  So, I will collapse the 2 subsections into 1.

Subsections under headings Developing -> Transactions ->How Geode Cache 
Transactions Work -> Transactions by Region Type -> Transactions and 
Partitioned Regions also have a subnav/markdown problem, so fixing this as well.


was (Author: karensmolermiller):
Since I'm already touching the section on transactions, I'm also going to fix a 
minor issue with the navigation links. The two subsections "About Transactions" 
and "Types of Transactions" are in the same file, and the subnav does not 
handle this case well.  So, I will collapse the 2 subsections into 1.

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (GEODE-2208) Document limitation of transactions on mixed region types

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller edited comment on GEODE-2208 at 12/13/16 10:17 PM:
---

Since I'm already touching the section on transactions, I'm also going to fix a 
minor issue with the navigation links. The two subsections "About Transactions" 
and "Types of Transactions" are in the same file, and the subnav does not 
handle this case well.  So, I will collapse the 2 subsections into 1.

Subsections under headings Developing -> Transactions ->Geode Cache 
Transactions -> How Geode Cache Transactions Work -> Transactions by Region 
Type -> Transactions and Partitioned Regions also have a subnav/markdown 
problem, so fixing this as well.


was (Author: karensmolermiller):
Since I'm already touching the section on transactions, I'm also going to fix a 
minor issue with the navigation links. The two subsections "About Transactions" 
and "Types of Transactions" are in the same file, and the subnav does not 
handle this case well.  So, I will collapse the 2 subsections into 1.

Subsections under headings Developing -> Transactions ->How Geode Cache 
Transactions Work -> Transactions by Region Type -> Transactions and 
Partitioned Regions also have a subnav/markdown problem, so fixing this as well.

> Document limitation of transactions on mixed region types
> -
>
> Key: GEODE-2208
> URL: https://issues.apache.org/jira/browse/GEODE-2208
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> For transactions that run on a mix of replicated and partitioned regions, the 
> first operation needs to be to a partitioned region.  This sets/fixes the 
> host where subsequent operations will run, and it will be where data is 
> colocated if there are multiple partitioned regions involved. If the first 
> operation is to the replicated region, then the host set may be one that is 
> not where the colocated data is, leading to data not colocated exceptions.
> This limitation needs to be documented.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2196:


Commit dc11cfa29462c5f1c8f2d344078bbc047fb64841 in geode's branch 
refs/heads/feature/GEODE-2196 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=dc11cfa ]

GEODE-2196: restore the system properties correctly in each vm


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2196:


Commit a43941c745c0a1553dfb88c2f2d3087358d676e9 in geode's branch 
refs/heads/feature/GEODE-2196 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=a43941c ]

GEODE-2196: add more tests to cover import cluster-configuration and deploy


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-419) javax.net.ssl.* gemfire properties ignored if ssl-enabled is false

[Udo Kohlmeyer (JIRA)]

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

Udo Kohlmeyer commented on GEODE-419:
-

I believe that this anomaly has now been fixed with the new 
SSLConfigurationFactory implementation. IF ssl is enabled (by either 
ssl-enabled=true or *-ssl-enabled=true) the configuration will try all possible 
avenues to configure the ssl properties. As a last resort it will use the 
java.net.ssl.* properties.
Maybe we need to add a test to explicitly test this, but I believe it is now 
resolved.

> javax.net.ssl.* gemfire properties ignored if ssl-enabled is false
> --
>
> Key: GEODE-419
> URL: https://issues.apache.org/jira/browse/GEODE-419
> Project: Geode
>  Issue Type: Bug
>  Components: configuration
>Reporter: Darrel Schneider
>Priority: Minor
>
> You are supposed to be able to put javax.net.ssl.* system property 
> definitions in your gemfire.properties and have them be used to configure ssl.
> They work ok if ssl-enabled is true and cluster-ssl-enabled is not set. But 
> if you set cluster-ssl-enabled (to true or false) then the javax.net.ssl.* 
> properties are ignored. The same is also true for http-service-ssl-enabled.
> This can be worked around by using the new cluster-ssl-keystore* and 
> cluster-ssl-truststore* gemfire properties instead of javax.net.ssl.*.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Karen Miller]

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

Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.


Repository: geode


Description
---

- First operation to a transactional system which has colocated
data and replicated/distributed regions must be to a
partitioned region (with colocated data), to set the transaction
host.  Note that this was already documented, but not in a
prominent place.  Now the basics of this info is repeated in
a less-buried location.
- Fixed poorly-working links within the subnav and fixed a
couple of markdown errors.  The errors were improperly
specified anchor tags.


Diffs
-

  geode-book/master_middleman/source/subnavs/geode-subnav.erb 
16aa1e78cb4ca64489c3c2c5d9fd4240684b0858 
  
geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
 fa3318a38356963262ea342d39fa98940812aa7e 
  geode-docs/developing/transactions/chapter_overview.html.md.erb 
b5e84a415451074e1ec803e0add20c7fe3272408 
  
geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb 
d96de82fa7d5f4074c88863c1732363530c12d39 

Diff: https://reviews.apache.org/r/54723/diff/


Testing
---

gradle rat check passes

Geode book builds with no broken links


Thanks,

Karen Miller

[GitHub] geode pull request #313: [GEODE-1407] Change a FlakyTest to distributedTest.

[galen-pivotal]

GitHub user galen-pivotal opened a pull request:

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

[GEODE-1407] Change a FlakyTest to distributedTest.

* remove `FlakyTest` from `ReconnectDUnitTest.testReconnectALocator`.
* use Awaitility instead of Wait.

This test doesn't seem to have failed in a while and I haven't been able to 
reproduce on my machine. Hopefully it was due to another test and we never have 
to worry about this again.

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

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

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

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


commit 57ef4fcc6357344fb7dad2236266b69cf2c322e7
Author: Galen O'Sullivan 
Date:   2016-12-13T22:49:25Z

[GEODE-1407] Change a FlakyTest to distributedTest.

* remove `FlakyTest` from `ReconnectDUnitTest.testReconnectALocator`.
* use Awaitility instead of Wait.




---
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-1407) CI Failure: ReconnectDUnitTest.testReconnectALocator

[ASF GitHub Bot (JIRA)]

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

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

GitHub user galen-pivotal opened a pull request:

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

[GEODE-1407] Change a FlakyTest to distributedTest.

* remove `FlakyTest` from `ReconnectDUnitTest.testReconnectALocator`.
* use Awaitility instead of Wait.

This test doesn't seem to have failed in a while and I haven't been able to 
reproduce on my machine. Hopefully it was due to another test and we never have 
to worry about this again.

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

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

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

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


commit 57ef4fcc6357344fb7dad2236266b69cf2c322e7
Author: Galen O'Sullivan 
Date:   2016-12-13T22:49:25Z

[GEODE-1407] Change a FlakyTest to distributedTest.

* remove `FlakyTest` from `ReconnectDUnitTest.testReconnectALocator`.
* use Awaitility instead of Wait.




> CI Failure: ReconnectDUnitTest.testReconnectALocator
> 
>
> Key: GEODE-1407
> URL: https://issues.apache.org/jira/browse/GEODE-1407
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Sai Boorlagadda
>  Labels: ci
>
> Related to GEODE-598. Opening a new one.
> {noformat}
> Error Message
> junit.framework.AssertionFailedError: expected the restarted member to be 
> hosting a running locator
> Stacktrace
> junit.framework.AssertionFailedError: expected the restarted member to be 
> hosting a running locator
>   at junit.framework.Assert.fail(Assert.java:57)
>   at junit.framework.TestCase.fail(TestCase.java:227)
>   at 
> com.gemstone.gemfire.cache30.ReconnectDUnitTest.testReconnectALocator(ReconnectDUnitTest.java:548)
>   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 junit.framework.TestCase.runTest(TestCase.java:176)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112)
>   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:66)
>   at 
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.gradle.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: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.reflec

Re: Review Request 54723: GEODE-2208 Document transactions limitation with mixed region types.

[Eric Shu]

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




geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb 
(line 44)


Product may throw TransactionDataRebalancedException instead of 
TransactionDataNotColocatedException. Do we need to specify exact exception?


- Eric Shu


On Dec. 13, 2016, 10:49 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54723/
> ---
> 
> (Updated Dec. 13, 2016, 10:49 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Eric Shu, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - First operation to a transactional system which has colocated
> data and replicated/distributed regions must be to a
> partitioned region (with colocated data), to set the transaction
> host.  Note that this was already documented, but not in a
> prominent place.  Now the basics of this info is repeated in
> a less-buried location.
> - Fixed poorly-working links within the subnav and fixed a
> couple of markdown errors.  The errors were improperly
> specified anchor tags.
> 
> 
> Diffs
> -
> 
>   geode-book/master_middleman/source/subnavs/geode-subnav.erb 
> 16aa1e78cb4ca64489c3c2c5d9fd4240684b0858 
>   
> geode-docs/developing/transactions/cache_transactions_by_region_type.html.md.erb
>  fa3318a38356963262ea342d39fa98940812aa7e 
>   geode-docs/developing/transactions/chapter_overview.html.md.erb 
> b5e84a415451074e1ec803e0add20c7fe3272408 
>   
> geode-docs/developing/transactions/data_location_cache_transactions.html.md.erb
>  d96de82fa7d5f4074c88863c1732363530c12d39 
> 
> Diff: https://reviews.apache.org/r/54723/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> Geode book builds with no broken links
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

[jira] [Commented] (GEODE-105) Null value in Map causes NPE with Map Indexes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-105:
---

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

GEODE-105: Add test index creation after null map values are in region


> Null value in Map causes NPE with Map Indexes
> -
>
> Key: GEODE-105
> URL: https://issues.apache.org/jira/browse/GEODE-105
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: Jason Huynh
> Fix For: 1.0.0-incubating.M1
>
>
> When a value of null is added into a map that is being indexed on, a NPE will 
> be thrown.  This should not happen and instead should be handled correcty 
> with the NULL token.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-1166) Attempting to connect to a locator using SSL fails

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-1166:
--

The new test ConnectToLocatorSSLDUnitTest should confirm that this bug was 
fixed by all of the SSL and Security work done for Geode 1.0.0. It would be 
good to retry what's in the description as well before closing the ticket.


> Attempting to connect to a locator using SSL fails
> --
>
> Key: GEODE-1166
> URL: https://issues.apache.org/jira/browse/GEODE-1166
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Barry Oglesby
>
> {noformat}
> gfsh>connect --locator=localhost[10331] 
> --security-properties-file=/path/to/gemfire-security.properties
> Connecting to Locator at [host=localhost, port=10331] ..
> Could not connect to Locator at [host=localhost, port=10331].
> Possible reason: Wrong or no SSL configuration provided. Please check logs 
> /path/to/gfsh-%u_%g.log
> {noformat}
> One thing is the gfsh log file name is wrong.
> But the main issue is that it doesn't connect.
> I traced this to {{TcpClient.requestToServer}}. Instead of using the SSL 
> {{SocketCreator}}, this method uses the non-SSL {{SocketCreator}} and fails 
> to connect.
> In GemFire 8.2.0.x, the SSL {{SocketCreator}} is initialized in 
> {{JmxManagerLocatorRequest.send}} like below before the call to 
> {{TcpClient.requestToServer}} is made.
> {noformat}
> SocketCreator.getDefaultInstance(distributionConfigProps);
> {noformat}
> This line doesn't exist in Geode. It looks like the change came in on commit 
> d2a942e8e5025b11432d87b5de902daae130aca7 of GEODE-77.
> As a test, I added that line back into {{JmxManagerLocatorRequest.send}}, and 
> the SSL connection was made successfully.
> I'm not really sure why this line was taken out, so I don't know whether this 
> change can be made. Another option would be to pass the 
> {{distributionConfigProps}} to {{TcpClient.requestToServer}} and use them to 
> create the SSL {{SocketCreator}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Review Request 54586: GEODE-2172: CustomConfigWithCacheIntegrationTest fails with AssertionError on Windows

[Jinmei Liao]

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




geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java
 (line 53)


Looks like this method is also used in 
CustomConfigWithLogServiceIntegrationTest. Did you also run that test on both 
platform as well?



geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java
 (line 60)


Looks like this method is never used in the project. We can either delete 
it or refactor the previous method to call this method.


- Jinmei Liao


On Dec. 13, 2016, 11:13 p.m., Kai Jiang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54586/
> ---
> 
> (Updated Dec. 13, 2016, 11:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Dan Smith.
> 
> 
> Bugs: geode-2172
> https://issues.apache.org/jira/browse/geode-2172
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> cacheLogWriterMessageShouldMatchCustomConfig fails with AssertionError.
> 
> The issues is related to incorrect regex pattern. The regex pattern used to 
> match log string contains newline character. To fix this issue, I've replaced 
> Unix newline character in regex pattern into `System.lineSeparator()`, a 
> Platform-dependent newline character in Java.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java
>  47515e6 
> 
> Diff: https://reviews.apache.org/r/54586/diff/
> 
> 
> Testing
> ---
> 
> I've run this unit test both on Windows and MacOS. And it passes.
> 
> 
> Thanks,
> 
> Kai Jiang
> 
>

Re: Review Request 54586: GEODE-2172: CustomConfigWithCacheIntegrationTest fails with AssertionError on Windows

[Kai Jiang]

> On Dec. 13, 2016, 3:33 p.m., Jinmei Liao wrote:
> > geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java,
> >  line 53
> > 
> >
> > Looks like this method is also used in 
> > CustomConfigWithLogServiceIntegrationTest. Did you also run that test on 
> > both platform as well?

Yes, I have tested this on both platforms(Windows 10 and macOS).


> On Dec. 13, 2016, 3:33 p.m., Jinmei Liao wrote:
> > geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java,
> >  line 60
> > 
> >
> > Looks like this method is never used in the project. We can either 
> > delete it or refactor the previous method to call this method.

Okay, got it.


- Kai


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


On Dec. 13, 2016, 3:13 p.m., Kai Jiang wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54586/
> ---
> 
> (Updated Dec. 13, 2016, 3:13 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Kirk Lund, and Dan Smith.
> 
> 
> Bugs: geode-2172
> https://issues.apache.org/jira/browse/geode-2172
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> cacheLogWriterMessageShouldMatchCustomConfig fails with AssertionError.
> 
> The issues is related to incorrect regex pattern. The regex pattern used to 
> match log string contains newline character. To fix this issue, I've replaced 
> Unix newline character in regex pattern into `System.lineSeparator()`, a 
> Platform-dependent newline character in Java.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/logging/log4j/custom/CustomConfiguration.java
>  47515e6 
> 
> Diff: https://reviews.apache.org/r/54586/diff/
> 
> 
> Testing
> ---
> 
> I've run this unit test both on Windows and MacOS. And it passes.
> 
> 
> Thanks,
> 
> Kai Jiang
> 
>

[jira] [Commented] (GEODE-2196) Write more tests to cover the current behavior of cluster config

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2196:


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

GEODE-2196: restore the system properties correctly in each vm


> Write more tests to cover the current behavior of cluster config
> 
>
> Key: GEODE-2196
> URL: https://issues.apache.org/jira/browse/GEODE-2196
> Project: Geode
>  Issue Type: Sub-task
>  Components: management
>Reporter: Jinmei Liao
>Assignee: Mark Bretl
> Fix For: 1.1.0
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (GEODE-2209) Only 16 GatewaySenders are supported

[Barry Oglesby (JIRA)]

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

Barry Oglesby updated GEODE-2209:
-
Issue Type: Improvement  (was: Bug)

> Only 16 GatewaySenders are supported
> 
>
> Key: GEODE-2209
> URL: https://issues.apache.org/jira/browse/GEODE-2209
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Mark Bretl
>
> If java assertions are enabled, attempting to use a 17th {{GatewaySender}}, 
> throws this {{AssertionError}}:
> {noformat}
> [severe 2016/12/13 15:58:08.456 PST gateway-ln-1  60712 Thread 0> tid=0x440] Server connection from 
> [identity(192.168.2.10(client:39966:loner):61377:e4369ffa:client,connection=2;
>  port=61377] : Unexpected Error on server
> java.lang.AssertionError
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$Bits.shift(ThreadIdentifier.java:126)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$WanType.generateWanId(ThreadIdentifier.java:74)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier.createFakeThreadIDForParallelGSPrimaryBucket(ThreadIdentifier.java:284)
>   at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderImpl.setModifiedEventId(SerialGatewaySenderImpl.java:248)
>   at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:849)
>   at 
> org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6367)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5909)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5750)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:337)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5730)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5374)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:381)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:777)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:908)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2209) Only 16 GatewaySenders are supported

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-2209:


 Summary: Only 16 GatewaySenders are supported
 Key: GEODE-2209
 URL: https://issues.apache.org/jira/browse/GEODE-2209
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Barry Oglesby
Assignee: Mark Bretl


If java assertions are enabled, attempting to use a 17th {{GatewaySender}}, 
throws this {{AssertionError}}:
{noformat}
[severe 2016/12/13 15:58:08.456 PST gateway-ln-1  tid=0x440] Server connection from 
[identity(192.168.2.10(client:39966:loner):61377:e4369ffa:client,connection=2; 
port=61377] : Unexpected Error on server
java.lang.AssertionError
at 
org.apache.geode.internal.cache.ha.ThreadIdentifier$Bits.shift(ThreadIdentifier.java:126)
at 
org.apache.geode.internal.cache.ha.ThreadIdentifier$WanType.generateWanId(ThreadIdentifier.java:74)
at 
org.apache.geode.internal.cache.ha.ThreadIdentifier.createFakeThreadIDForParallelGSPrimaryBucket(ThreadIdentifier.java:284)
at 
org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderImpl.setModifiedEventId(SerialGatewaySenderImpl.java:248)
at 
org.apache.geode.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:849)
at 
org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6367)
at 
org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5909)
at 
org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
at 
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5750)
at 
org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:337)
at 
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
at 
org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5730)
at 
org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5374)
at 
org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:381)
at 
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:777)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:908)
at 
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
at java.lang.Thread.run(Thread.java:745)
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2209) Only 16 GatewaySenders are supported

[Barry Oglesby (JIRA)]

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

Barry Oglesby reassigned GEODE-2209:


Assignee: Barry Oglesby  (was: Mark Bretl)

> Only 16 GatewaySenders are supported
> 
>
> Key: GEODE-2209
> URL: https://issues.apache.org/jira/browse/GEODE-2209
> Project: Geode
>  Issue Type: Improvement
>  Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> If java assertions are enabled, attempting to use a 17th {{GatewaySender}}, 
> throws this {{AssertionError}}:
> {noformat}
> [severe 2016/12/13 15:58:08.456 PST gateway-ln-1  60712 Thread 0> tid=0x440] Server connection from 
> [identity(192.168.2.10(client:39966:loner):61377:e4369ffa:client,connection=2;
>  port=61377] : Unexpected Error on server
> java.lang.AssertionError
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$Bits.shift(ThreadIdentifier.java:126)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier$WanType.generateWanId(ThreadIdentifier.java:74)
>   at 
> org.apache.geode.internal.cache.ha.ThreadIdentifier.createFakeThreadIDForParallelGSPrimaryBucket(ThreadIdentifier.java:284)
>   at 
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderImpl.setModifiedEventId(SerialGatewaySenderImpl.java:248)
>   at 
> org.apache.geode.internal.cache.wan.AbstractGatewaySender.distribute(AbstractGatewaySender.java:849)
>   at 
> org.apache.geode.internal.cache.LocalRegion.notifyGatewaySender(LocalRegion.java:6367)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5909)
>   at 
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2800)
>   at 
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5750)
>   at 
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:337)
>   at 
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:151)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5730)
>   at 
> org.apache.geode.internal.cache.LocalRegion.basicBridgePut(LocalRegion.java:5374)
>   at 
> org.apache.geode.internal.cache.tier.sockets.command.Put65.cmdExecute(Put65.java:381)
>   at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:777)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:908)
>   at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1165)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (GEODE-2210) Session module class loader should check the thread context class loader

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-2210:
--

 Summary: Session module class loader should check the thread 
context class loader
 Key: GEODE-2210
 URL: https://issues.apache.org/jira/browse/GEODE-2210
 Project: Geode
  Issue Type: Bug
  Components: http session
Reporter: Jason Huynh
Assignee: Mark Bretl


The current behavior uses Class.forName() to load classes.  There are cases 
where the context class loader contains the class and are hidden from the top 
level class loader.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-2210) Session module class loader should check the thread context class loader

[Jason Huynh (JIRA)]

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

Jason Huynh reassigned GEODE-2210:
--

Assignee: Jason Huynh  (was: Mark Bretl)

> Session module class loader should check the thread context class loader
> 
>
> Key: GEODE-2210
> URL: https://issues.apache.org/jira/browse/GEODE-2210
> Project: Geode
>  Issue Type: Bug
>  Components: http session
>Reporter: Jason Huynh
>Assignee: Jason Huynh
>
> The current behavior uses Class.forName() to load classes.  There are cases 
> where the context class loader contains the class and are hidden from the top 
> level class loader.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #314: GEODE-789: Added 'create defined indexes', 'clear d...

[ameybarve15]

GitHub user ameybarve15 opened a pull request:

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

GEODE-789: Added 'create defined indexes', 'clear defined indexes', and  
'define index' for CliAvailabilityIndicator

Added 'create defined indexes', 'clear defined indexes', and 'define index' 
gfsh commands for indexes in CliAvailabilityIndicator so that they would not be 
available on a disconnected gfsh session. 
Fixed testOfflineHelp.



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

$ git pull https://github.com/ameybarve15/incubator-geode feature/GEODE-789

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

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


commit 20f46db250e326ba25e02c8fdd9ef78f45106246
Author: Amey Barve 
Date:   2016-12-13T05:31:49Z

GEODE-789: Added 'create defined indexes', 'clear defined indexes', and
'define index' gfsh commands for indexes in CliAvailabilityIndicator so
that they would not be available on a disconnected gfsh session. Fixed
testOfflineHelp.




---
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-789) Create and clear define index shouldn't be available on disconnected GFSH

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-789:
--

GitHub user ameybarve15 opened a pull request:

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

GEODE-789: Added 'create defined indexes', 'clear defined indexes', and  
'define index' for CliAvailabilityIndicator

Added 'create defined indexes', 'clear defined indexes', and 'define index' 
gfsh commands for indexes in CliAvailabilityIndicator so that they would not be 
available on a disconnected gfsh session. 
Fixed testOfflineHelp.



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

$ git pull https://github.com/ameybarve15/incubator-geode feature/GEODE-789

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

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


commit 20f46db250e326ba25e02c8fdd9ef78f45106246
Author: Amey Barve 
Date:   2016-12-13T05:31:49Z

GEODE-789: Added 'create defined indexes', 'clear defined indexes', and
'define index' gfsh commands for indexes in CliAvailabilityIndicator so
that they would not be available on a disconnected gfsh session. Fixed
testOfflineHelp.




> Create and clear define index shouldn't be available on disconnected GFSH
> -
>
> Key: GEODE-789
> URL: https://issues.apache.org/jira/browse/GEODE-789
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, tools
>Reporter: William Markito Oliveira
>Assignee: Amey Barve
>
> The following gfsh commands for indexes shouldn't be available on a 
> disconnected gfsh session. 
> {code}
> gfsh>create defined indexes --
> Can't execute a remote command without connection. Use 'connect' first to 
> connect.
> gfsh>clear defined indexes
> Can't execute a remote command without connection. Use 'connect' first to 
> connect.
> gfsh>
> {code} 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (GEODE-734) gfsh export stack-traces should not require an output file with extension .txt

[Deepak Dixit (JIRA)]

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

Deepak Dixit reassigned GEODE-734:
--

Assignee: Deepak Dixit

> gfsh export stack-traces should not require an output file with extension .txt
> --
>
> Key: GEODE-734
> URL: https://issues.apache.org/jira/browse/GEODE-734
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Deepak Dixit
> Fix For: 1.1.0
>
>
> gfsh {{export stack-traces}} requires a file with a {{.txt}} extension:
> {noformat}
> gfsh>export stack-traces --file=/tmp/trace.log
> Invalid file type, the file extension must be ".txt"
> {noformat}
> This seems like a totally arbitrary restriction. Please can it be removed.
> If the concern is that an existing file might be overwritten then we should 
> have a user prompt indicating that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2061) Remove PdxInstanceInputStream

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2061:


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

GEODE-2061: Removed PdxInstanceInputStream and its references replace by 
PdxInputStream

GEODE-2061: Construct PdxInputStream properly.

GEODE-2061: fixing spotlessJavaCheck


> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2061) Remove PdxInstanceInputStream

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2061:


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

GEODE-2061: Removed PdxInstanceInputStream and its references replace by 
PdxInputStream

GEODE-2061: Construct PdxInputStream properly.

GEODE-2061: fixing spotlessJavaCheck


> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (GEODE-2061) Remove PdxInstanceInputStream

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2061:


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

GEODE-2061: Removed PdxInstanceInputStream and its references replace by 
PdxInputStream

GEODE-2061: Construct PdxInputStream properly.

GEODE-2061: fixing spotlessJavaCheck


> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #312: [GEODE-2061] Fix for Remove PdxInstanceInputStream

[davinash]

Github user davinash closed the pull request at:

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


---
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-2061) Remove PdxInstanceInputStream

[ASF GitHub Bot (JIRA)]

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

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

Github user davinash closed the pull request at:

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


> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] geode pull request #315: GEODE-1995: Removed ReliableMessageQueue, ReliableM...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory…

…, ReliableMessageQueueFactoryImpl and

it's usage in the code from GemfireCacheImpl and DistributedRegion.

CC @dschneider-pivotal 

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

$ git pull https://github.com/davinash/geode feature/GEODE-1995

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

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


commit 7fdf95086d1f31e5520c449c254a9a07d813fbe8
Author: adongre 
Date:   2016-12-13T07:20:31Z

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory, 
ReliableMessageQueueFactoryImpl and
it's usage in the code from GemfireCacheImpl and DistributedRegion.




---
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-1995) remove ReliableMessageQueueFactory, ReliableMessageQueue, and getReliableMessageQueueFactory

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davinash opened a pull request:

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

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory…

…, ReliableMessageQueueFactoryImpl and

it's usage in the code from GemfireCacheImpl and DistributedRegion.

CC @dschneider-pivotal 

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

$ git pull https://github.com/davinash/geode feature/GEODE-1995

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

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


commit 7fdf95086d1f31e5520c449c254a9a07d813fbe8
Author: adongre 
Date:   2016-12-13T07:20:31Z

GEODE-1995: Removed ReliableMessageQueue, ReliableMessageQueueFactory, 
ReliableMessageQueueFactoryImpl and
it's usage in the code from GemfireCacheImpl and DistributedRegion.




> remove ReliableMessageQueueFactory, ReliableMessageQueue, and 
> getReliableMessageQueueFactory
> 
>
> Key: GEODE-1995
> URL: https://issues.apache.org/jira/browse/GEODE-1995
> Project: Geode
>  Issue Type: Improvement
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Avinash Dongre
>
> ReliableMessageQueueFactory, ReliableMessageQueue, and 
> GemFireCacheImpl.getReliableMessageQueueFactory should all be removed. They 
> are internal and were never used. No tests exist for them.
> They are part of required Roles which is a deprecated feature.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-2061) Remove PdxInstanceInputStream

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-2061.
---
Resolution: Fixed

> Remove PdxInstanceInputStream
> -
>
> Key: GEODE-2061
> URL: https://issues.apache.org/jira/browse/GEODE-2061
> Project: Geode
>  Issue Type: Improvement
>  Components: serialization
>Reporter: Bruce Schuchardt
>Assignee: Avinash Dongre
>
> This class should be removed and its uses replaced with its superclass 
> PdxInputStream.  None of the methods it contains differs from the superclass 
> implementation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (GEODE-1984) Make GatewaySender destroy a public API

[Avinash Dongre (JIRA)]

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

Avinash Dongre resolved GEODE-1984.
---
Resolution: Fixed

> Make GatewaySender destroy a public API
> ---
>
> Key: GEODE-1984
> URL: https://issues.apache.org/jira/browse/GEODE-1984
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, wan
>Reporter: Barry Oglesby
>Assignee: Avinash Dongre
>
> The internal {{AbstractGatewaySender}} class has a {{destroy}} API to destroy 
> a {{GatewaySender}}. This is currently an internal API. It would be nice to 
> make this public by:
> - adding destroy to the {{GatewaySender}} interface
> - provide {{gfsh}} support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)