[jira] [Commented] (GEODE-1549) Incorrect "Help" hyperlink in pulse

[ASF GitHub Bot (JIRA)]

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

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

GitHub user smanvi-pivotal opened a pull request:

https://github.com/apache/incubator-geode/pull/161

GEODE-1549: Correct "Help" hyperlink in pulse

The Help hyperlink in the Pulse UI was incorrect. 

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

$ git pull https://github.com/smanvi-pivotal/incubator-geode 
feature/GEODE-1549

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

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


commit 6609989808b67c59b07f9c1677e12c379b716470
Author: Srikanth Manvi 
Date:   2016-06-16T03:13:58Z

GEODE-1549: Correct "Help" hyperlink in pulse




> Incorrect "Help" hyperlink in pulse
> ---
>
> Key: GEODE-1549
> URL: https://issues.apache.org/jira/browse/GEODE-1549
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Srikanth Manvi
>Assignee: Srikanth Manvi
>Priority: Minor
>
> When we click on "Help" link on the top right corner in pulse we get 
> PageNotFound



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

[jira] [Created] (GEODE-1553) CI Failure: SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped

[Scott Jewell (JIRA)]

Scott Jewell created GEODE-1553:
---

 Summary: CI Failure: 
SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped
 Key: GEODE-1553
 URL: https://issues.apache.org/jira/browse/GEODE-1553
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Scott Jewell


Member is force disconnected due to no heartbeat 

com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.internal.cache.wan.WANTestBase$$Lambda$20/1962935211.run 
in VM 7 running on Host kuwait.gemstone.com with 8 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
at 
com.gemstone.gemfire.internal.cache.wan.WANTestBase.createCacheInVMs(WANTestBase.java:866)
at 
com.gemstone.gemfire.internal.cache.wan.serial.SerialWANPropogationDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped(SerialWANPropogationDUnitTest.java:638)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java: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.GeneratedMethodAccessor200.invoke(Unknown Source)
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.GeneratedMethodAccessor199.invoke(Unknown Source)
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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 

[jira] [Created] (GEODE-1552) CI Failure: SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped

[Scott Jewell (JIRA)]

Scott Jewell created GEODE-1552:
---

 Summary: CI Failure: 
SerialWANPropogationOffHeapDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped
 Key: GEODE-1552
 URL: https://issues.apache.org/jira/browse/GEODE-1552
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Scott Jewell


Member is force disconnected due to no heartbeat 

com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.internal.cache.wan.WANTestBase$$Lambda$20/1962935211.run 
in VM 7 running on Host kuwait.gemstone.com with 8 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
at 
com.gemstone.gemfire.internal.cache.wan.WANTestBase.createCacheInVMs(WANTestBase.java:866)
at 
com.gemstone.gemfire.internal.cache.wan.serial.SerialWANPropogationDUnitTest.testReplicatedSerialPropagationWithRemoteReceiverStopped(SerialWANPropogationDUnitTest.java:638)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java: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.GeneratedMethodAccessor200.invoke(Unknown Source)
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.GeneratedMethodAccessor199.invoke(Unknown Source)
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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
at 
org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
at 

[jira] [Updated] (GEODE-1551) CommandOverHttpDUnitTest

[Scott Jewell (JIRA)]

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

Scott Jewell updated GEODE-1551:

Assignee: Jinmei Liao

> CommandOverHttpDUnitTest
> 
>
> Key: GEODE-1551
> URL: https://issues.apache.org/jira/browse/GEODE-1551
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Scott Jewell
>Assignee: Jinmei Liao
>
> Various tests within the test suite are failing with the following error:
> Found suspect string in log4j at line 582
> [fatal 2016/06/14 21:03:21.748 PDT  tid=0x8d] 
> org.eclipse.jetty.io.EofException
>   at 
> org.eclipse.jetty.server.HttpConnection$SendCallback.reset(HttpConnection.java:663)
>   at 
> org.eclipse.jetty.server.HttpConnection$SendCallback.access$300(HttpConnection.java:627)
>   at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:508)
>   at 
> org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:668)
>   at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:722)
>   at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:177)
>   at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:163)
>   at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:297)



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

[jira] [Created] (GEODE-1551) CommandOverHttpDUnitTest

[Scott Jewell (JIRA)]

Scott Jewell created GEODE-1551:
---

 Summary: CommandOverHttpDUnitTest
 Key: GEODE-1551
 URL: https://issues.apache.org/jira/browse/GEODE-1551
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Scott Jewell


Various tests within the test suite are failing with the following error:

Found suspect string in log4j at line 582

[fatal 2016/06/14 21:03:21.748 PDT  tid=0x8d] 
org.eclipse.jetty.io.EofException
at 
org.eclipse.jetty.server.HttpConnection$SendCallback.reset(HttpConnection.java:663)
at 
org.eclipse.jetty.server.HttpConnection$SendCallback.access$300(HttpConnection.java:627)
at org.eclipse.jetty.server.HttpConnection.send(HttpConnection.java:508)
at 
org.eclipse.jetty.server.HttpChannel.sendResponse(HttpChannel.java:668)
at org.eclipse.jetty.server.HttpChannel.write(HttpChannel.java:722)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:177)
at org.eclipse.jetty.server.HttpOutput.write(HttpOutput.java:163)
at org.eclipse.jetty.server.HttpOutput.flush(HttpOutput.java:297)




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

[jira] [Commented] (GEODE-1550) MembershipJUnitTest.testMultipleManagersInSameProcess

[Scott Jewell (JIRA)]

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

Scott Jewell commented on GEODE-1550:
-

Scott J.  There is additional log output stating that an expected mock 
interaction did not take place:

Standard Error

Wanted but not invoked:
distributedMembershipListener.messageReceived(
isA(com.gemstone.gemfire.distributed.internal.SerialAckedMessage)
);
-> at 
com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:166)

However, there were other interactions with this mock:
distributedMembershipListener.getDM();
-> at 
com.gemstone.gemfire.distributed.internal.membership.gms.mgr.GMSMembershipManager.shutdownInProgress(GMSMembershipManager.java:1953)

distributedMembershipListener.viewInstalled(
View[rooktwo(2741):1024|1] members: 
[rooktwo(2741):1024{lead}, rooktwo(2741):1025]
);
-> at 
com.gemstone.gemfire.distributed.internal.membership.gms.mgr.GMSMembershipManager.join(GMSMembershipManager.java:655)

distributedMembershipListener.getDM();
-> at 
com.gemstone.gemfire.distributed.internal.membership.gms.mgr.GMSMembershipManager.shutdownInProgress(GMSMembershipManager.java:1953)


> MembershipJUnitTest.testMultipleManagersInSameProcess
> -
>
> Key: GEODE-1550
> URL: https://issues.apache.org/jira/browse/GEODE-1550
> Project: Geode
>  Issue Type: Bug
>  Components: membership, messaging
>Reporter: Scott Jewell
>  Labels: CI, ci
>
> java.lang.AssertionError: Expected a multicast message to be received
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   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 
> 

[jira] [Updated] (GEODE-1550) MembershipJUnitTest.testMultipleManagersInSameProcess

[Scott Jewell (JIRA)]

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

Scott Jewell updated GEODE-1550:

Component/s: membership

> MembershipJUnitTest.testMultipleManagersInSameProcess
> -
>
> Key: GEODE-1550
> URL: https://issues.apache.org/jira/browse/GEODE-1550
> Project: Geode
>  Issue Type: Bug
>  Components: membership, messaging
>Reporter: Scott Jewell
>  Labels: CI, ci
>
> java.lang.AssertionError: Expected a multicast message to be received
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   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.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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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 

[jira] [Updated] (GEODE-1550) MembershipJUnitTest.testMultipleManagersInSameProcess

[Scott Jewell (JIRA)]

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

Scott Jewell updated GEODE-1550:

Component/s: messaging

> MembershipJUnitTest.testMultipleManagersInSameProcess
> -
>
> Key: GEODE-1550
> URL: https://issues.apache.org/jira/browse/GEODE-1550
> Project: Geode
>  Issue Type: Bug
>  Components: messaging
>Reporter: Scott Jewell
>  Labels: CI, ci
>
> java.lang.AssertionError: Expected a multicast message to be received
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   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.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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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 

[jira] [Updated] (GEODE-1550) MembershipJUnitTest.testMultipleManagersInSameProcess

[Scott Jewell (JIRA)]

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

Scott Jewell updated GEODE-1550:

Labels: CI ci  (was: )

> MembershipJUnitTest.testMultipleManagersInSameProcess
> -
>
> Key: GEODE-1550
> URL: https://issues.apache.org/jira/browse/GEODE-1550
> Project: Geode
>  Issue Type: Bug
>Reporter: Scott Jewell
>  Labels: CI, ci
>
> java.lang.AssertionError: Expected a multicast message to be received
>   at org.junit.Assert.fail(Assert.java:88)
>   at 
> com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   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.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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   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)



--
This message was sent 

[jira] [Created] (GEODE-1550) MembershipJUnitTest.testMultipleManagersInSameProcess

[Scott Jewell (JIRA)]

Scott Jewell created GEODE-1550:
---

 Summary: MembershipJUnitTest.testMultipleManagersInSameProcess
 Key: GEODE-1550
 URL: https://issues.apache.org/jira/browse/GEODE-1550
 Project: Geode
  Issue Type: Bug
Reporter: Scott Jewell


java.lang.AssertionError: Expected a multicast message to be received
at org.junit.Assert.fail(Assert.java:88)
at 
com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
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.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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
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)




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

[jira] [Commented] (GEODE-1525) geode-examples rely on GEODE_HOME env variable

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/incubator-geode/pull/160

GEODE-1525: Examples README.md should set env variable

GEODE-1523: Improve examples README.md markdown

This PR fixes addresses both GEODE-1525 and GEODE-1523, as they
both change the contents of the same file: geode-examples/README.md.

- Each example will likely use a scripts/setEnv.sh script to set
  the path to gfsh. The script depends on a GEODE_HOME environment
  variable, so this top level of instructions for setting up
  the examples now tells the user to set a GEODE_HOME env variable
  directly after the installation.

- Implement a more strict markdown that displays correctly for a
  wide variety of markdown implementations.

- Put in links for the 3 references.

- Improve the prose.

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

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

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

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


commit 21d30ab92d2a2146207186a690eb5a36d42e7059
Author: Karen Miller 
Date:   2016-06-15T22:30:03Z

GEODE-1525: Examples README.md should set env variable
GEODE-1523: Improve examples README.md markdown

This PR fixes addresses both GEODE-1525 and GEODE-1523, as they
both change the contents of the same file: geode-examples/README.md.

- Each example will likely use a scripts/setEnv.sh script to set
  the path to gfsh. The script depends on a GEODE_HOME environment
  variable, so this top level of instructions for setting up
  the examples now tells the user to set a GEODE_HOME env variable
  directly after the installation.

- Implement a more strict markdown that displays correctly for a
  wide variety of markdown implementations.

- Put in links for the 3 references.

- Improve the prose.




> geode-examples rely on GEODE_HOME env variable
> --
>
> Key: GEODE-1525
> URL: https://issues.apache.org/jira/browse/GEODE-1525
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
>
> Work currently on the feature/GEODE-33 branch.
> The script {{setEnv.sh}} in the first example (Replicated Region) relies on 
> the user setting the environment variable, {{GEODE_HOME}}, in order to invoke 
> gfsh.  This is fine, and the script would fail, telling the user to set the 
> variable. So, things work.  
> However, it is likely that many examples will want this same env variable 
> set. Therefore, the top level {{README.md}} should contain a step, perhaps 
> directly after the link to the installation instructions that directs a user 
> to set a {{GEODE_HOME}} environment variable.
> Then, as more examples are added, they can copy the Replicated Region's 
> {{setEnv.sh}} script and also use it.



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

[jira] [Commented] (GEODE-1521) APP_FETCH_SIZE in GFSH should not be applied to COUNT queries

[ASF GitHub Bot (JIRA)]

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

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

Github user kirklund commented on the issue:

https://github.com/apache/incubator-geode/pull/155
  
I've pulled this in and I'm running precheckin on it.


> APP_FETCH_SIZE in GFSH should not be applied to COUNT queries
> -
>
> Key: GEODE-1521
> URL: https://issues.apache.org/jira/browse/GEODE-1521
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> There are more varieties of count than simply * within the count().  
> Specifically, one can do:  {{count(distinct(field))}} or {{count(field)}}
> This makes checking for only {{count( * )}} incorrect.  Instead, the search 
> to apply the limt should look for {{" count("}}



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

[jira] [Resolved] (GEODE-1522) Lucene WiKi page issues

[Dan Smith (JIRA)]

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

Dan Smith resolved GEODE-1522.
--
Resolution: Fixed

1. Added Not yet implemented to the gfsh section
2. Updated the example
3. Update the Key Points section
4. Updated the example xml. I think it might be because we changed the xsd 
location of cache.xsd since this document was written.

> Lucene WiKi page issues
> ---
>
> Key: GEODE-1522
> URL: https://issues.apache.org/jira/browse/GEODE-1522
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jinmei Liao
>  Labels: bug-hunt
>
> 1. The Gfsh support isn't implemented yet. Maybe mention that in the doc, say 
> "to be coming later".
> 2. The LuceneService.createIndex returns null instead of a lucene index, but 
> the code sample indicates otherwise.
> 3. In section "Key Points" #4, the index should be created before the region 
> is created, not before inserting data.
> 4. The xml sample provided in the wiki doesn't work out of the box. I think 
> it's missing a quote and an ending cache for it to be a valid xml, but even 
> if we added those, it's still complaining something about "Cannot find the 
> declaration of element 'cache'.".



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

[jira] [Assigned] (GEODE-1549) Incorrect "Help" hyperlink in pulse

[Srikanth Manvi (JIRA)]

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

Srikanth Manvi reassigned GEODE-1549:
-

Assignee: Srikanth Manvi

> Incorrect "Help" hyperlink in pulse
> ---
>
> Key: GEODE-1549
> URL: https://issues.apache.org/jira/browse/GEODE-1549
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Srikanth Manvi
>Assignee: Srikanth Manvi
>Priority: Minor
>
> When we click on "Help" link on the top right corner in pulse we get 
> PageNotFound



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

[jira] [Updated] (GEODE-1549) Incorrect "Help" hyperlink in pulse

[Srikanth Manvi (JIRA)]

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

Srikanth Manvi updated GEODE-1549:
--
Priority: Minor  (was: Major)

> Incorrect "Help" hyperlink in pulse
> ---
>
> Key: GEODE-1549
> URL: https://issues.apache.org/jira/browse/GEODE-1549
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Reporter: Srikanth Manvi
>Priority: Minor
>
> When we click on "Help" link on the top right corner in pulse we get 
> PageNotFound



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

[jira] [Created] (GEODE-1549) Incorrect "Help" hyperlink in pulse

[Srikanth Manvi (JIRA)]

Srikanth Manvi created GEODE-1549:
-

 Summary: Incorrect "Help" hyperlink in pulse
 Key: GEODE-1549
 URL: https://issues.apache.org/jira/browse/GEODE-1549
 Project: Geode
  Issue Type: Bug
  Components: pulse
Reporter: Srikanth Manvi


When we click on "Help" link on the top right corner in pulse we get 
PageNotFound



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

[jira] [Updated] (GEODE-215) Provide ability to create regions from client

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-215:
---
Component/s: security

> Provide ability to create regions from client
> -
>
> Key: GEODE-215
> URL: https://issues.apache.org/jira/browse/GEODE-215
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs, security
>Reporter: Swapnil Bawaskar
>
> Currently regions on the server are created through gfsh or by declaring them 
> in cache.xml. The API to create regions on client, creates regions only on 
> the client which then connects to an existing region on the server with the 
> same name. 
> h4. New API
> The improvement proposed here is to provide an API from the client to create 
> regions on the server.
> The current client API to create regions is:
> {code}
> clientCache.createClientRegionFactory(ClientRegionShortcut).create();
> {code}
> For applications that embed GemFire servers, there is already an API to 
> create regions on the servers:
> {code}
> cache.createRegionFactory(RegionShortcut).create();
> {code}
> The clients should support this API so that it can create regions on the 
> server. Since this method returns a Region, we should create a 
> ClientRegionShortcut.PROXY region on the client. If a different region type 
> is desired on the client, users can first use createClientRegionFactory() to 
> create the region on the client followed by using createRegionFactory() to 
> create the region on the server.
> h4. Destroy Region
> For destroying a region, we already have two APIs on the region 
> destroyRegion() and localDestroyRegion().
> The clients could use destroyRegion() to destroy the region on the server and 
> use localDestroyRegion() to destroy the region locally.
> Currently, destroyRegion() is not distributed to others if the scope of the 
> region is LOCAL (which is the case of client regions).
> Although the proposal here will break backwards compatibility, I feel we 
> should make this change to make the API more intuitive.



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

[jira] [Commented] (GEODE-1531) geode-examples: add final step to run stop script

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/incubator-geode/pull/159

GEODE-1531: Improve README.md for replicated example

- Improved the appearance of the markdown

- Added commands for how to kill a single server

- Added last step to run scripts/stopAll.sh so the system is
  shut down when the example ends, not leaving a locator and
  a server running

- Improved the prose describing what the example does

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

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

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

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


commit d2ec280df6d3feacccdb5dba4a114ef086a71717
Author: Karen Miller 
Date:   2016-06-15T21:34:37Z

GEODE-1531: Improve README.md for replicated example

- Improved the appearance of the markdown

- Added commands for how to kill a single server

- Added last step to run scripts/stopAll.sh so the system is
  shut down when the example ends, not leaving a locator and
  a server running

- Improved the prose describing what the example does




> geode-examples:  add final step to run stop script
> --
>
> Key: GEODE-1531
> URL: https://issues.apache.org/jira/browse/GEODE-1531
> Project: Geode
>  Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
>
> {{replicated/README.md}} steps 1-5 of the replicated example in 
> geode-examples on the feature/GEODE-33 branch are fine.  (Well, step 4 to 
> kill a *server* needs to be specified.)
> A Step 6 needs to be added to the {{replicated/README.md}} file to run 
> {{$ scripts/stopAll.sh}}
> Without this, novice users will not realize that they still have servers and 
> a locator running.



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

[jira] [Resolved] (GEODE-305) Change BridgeServer to CacheServer

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt resolved GEODE-305.

   Resolution: Fixed
Fix Version/s: 1.0.0-incubating.M3

Apparently BridgeServer has already been removed from Geode, so I'm closing 
this ticket.

> Change BridgeServer to CacheServer
> --
>
> Key: GEODE-305
> URL: https://issues.apache.org/jira/browse/GEODE-305
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server
>Reporter: Darrel Schneider
>Priority: Minor
> Fix For: 1.0.0-incubating.M3
>
>
> The term BridgeServer is deprecated and CacheServer should be used instead. 
> Even with the removal of the deprecated BridgeServer api many uses of it 
> remain in test method names.



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

[jira] [Updated] (GEODE-388) DynamicRegionFactory should be deprecated

[Bruce Schuchardt (JIRA)]

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

Bruce Schuchardt updated GEODE-388:
---
Component/s: (was: client/server)
 regions

> DynamicRegionFactory should be deprecated
> -
>
> Key: GEODE-388
> URL: https://issues.apache.org/jira/browse/GEODE-388
> Project: Geode
>  Issue Type: Wish
>  Components: docs, regions
>Reporter: Kirk Lund
>
> DynamicRegionFactory should be deprecated.
> See GEODE-72 and GEODE-215.



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

[jira] [Assigned] (GEODE-1548) jmx-manager-hostname-for-clients not honored

[Kevin Duling (JIRA)]

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

Kevin Duling reassigned GEODE-1548:
---

Assignee: Kevin Duling

> jmx-manager-hostname-for-clients not honored
> 
>
> Key: GEODE-1548
> URL: https://issues.apache.org/jira/browse/GEODE-1548
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh, management
>Reporter: Swapnil Bawaskar
>Assignee: Kevin Duling
>
> While running Geode on AWS, found that {{jmx-manager-hostname-for-clients}} 
> is not being honored resulting in not being able to connect to gfsh from 
> outside AWS.
> I started a locator in AWS with the following command:
> {noformat}
> gfsh>start locator --name=locator 
> --J=-Dgemfire.jmx-manager-hostname-for-clients= 
> --hostname-for-clients=
> {noformat}
> When trying to connect to this locator from my laptop I get the following 
> error:
> {noformat}
> gfsh>connect --locator=52.41.104.182[10334]
> Connecting to Locator at [host=52.41.104.182, port=10334] ..
> Connecting to Manager at 
> [host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, port=1099] ..
> Could not connect to : 
> [host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, port=1099]. Failed 
> to retrieve RMIServer stub: javax.naming.CommunicationException [Root 
> exception is java.rmi.ConnectIOException: error during JRMP connection 
> establishment; nested exception is:
> java.net.SocketException: Connection reset]
> {noformat}
> Note that gfsh is trying to connect to the public dns for the instance, not 
> using the {{jmx-manager-hostname-for-clients}} property provided.



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

[jira] [Issue Comment Deleted] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-68:
--
Comment: was deleted

(was: Re-opening so it can be added to Pivotal Tracker.)

> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: gfsh
> Fix For: 1.0.0-incubating.M3
>
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.  
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- | 
> --
> APP_COLLECTION_LIMIT   | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS   | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE   | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME   | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER  | basic
> SYS_CLASSPATH  | 
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME  | wmarkito
> SYS_JAVA_VERSION   | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR  |
> SYS_USER   | wmarkito
> SYS_USER_HOME  | /Users/wmarkito
> {code}



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

[jira] [Resolved] (GEODE-748) Unexpected version string returned from gfsh

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-748.

Resolution: Fixed

> Unexpected version string returned from gfsh
> 
>
> Key: GEODE-748
> URL: https://issues.apache.org/jira/browse/GEODE-748
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> {{gfsh version}} returns a version number with a prepended 'v'. This is 
> inconsistent with the actual versioning which never includes a 'v'.
> The {{v}} should be removed from the specific gfsh command.



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

[jira] [Reopened] (GEODE-748) Unexpected version string returned from gfsh

[Kevin Duling (JIRA)]

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

Kevin Duling reopened GEODE-748:


> Unexpected version string returned from gfsh
> 
>
> Key: GEODE-748
> URL: https://issues.apache.org/jira/browse/GEODE-748
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> {{gfsh version}} returns a version number with a prepended 'v'. This is 
> inconsistent with the actual versioning which never includes a 'v'.
> The {{v}} should be removed from the specific gfsh command.



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

[jira] [Issue Comment Deleted] (GEODE-1521) APP_FETCH_SIZE in GFSH should not be applied to COUNT queries

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-1521:

Comment: was deleted

(was: Re-opening so it can be added to Pivotal Tracker.)

> APP_FETCH_SIZE in GFSH should not be applied to COUNT queries
> -
>
> Key: GEODE-1521
> URL: https://issues.apache.org/jira/browse/GEODE-1521
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> There are more varieties of count than simply * within the count().  
> Specifically, one can do:  {{count(distinct(field))}} or {{count(field)}}
> This makes checking for only {{count( * )}} incorrect.  Instead, the search 
> to apply the limt should look for {{" count("}}



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

[jira] [Issue Comment Deleted] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH

[Kevin Duling (JIRA)]

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

Kevin Duling updated GEODE-744:
---
Comment: was deleted

(was: Re-opening so it can be added to Pivotal Tracker.)

> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from 
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the 
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and, 
> afterwards, executes two queries, one using lower case and other using upper 
> case. You can see from the console that ouput is different, one returns the 
> actual size (1500) and the other one returns the default APP_FETCH_SIZE 
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner 
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to 
> compare strings without using the actual word case. Is not enough to add more 
> "or" to the comparison like we are currently doing with since keywords like 
> "Count" or "coUn" will still break the functionallity. We should compare 
> everything using lower case or upper case, it doesn't matter which one, or at 
> least make sure that gfsh converts the query to upper/lower case before 
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT")  query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}



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

[jira] [Created] (GEODE-1548) jmx-manager-hostname-for-clients not honored

[Swapnil Bawaskar (JIRA)]

Swapnil Bawaskar created GEODE-1548:
---

 Summary: jmx-manager-hostname-for-clients not honored
 Key: GEODE-1548
 URL: https://issues.apache.org/jira/browse/GEODE-1548
 Project: Geode
  Issue Type: Bug
  Components: gfsh, management
Reporter: Swapnil Bawaskar


While running Geode on AWS, found that {{jmx-manager-hostname-for-clients}} is 
not being honored resulting in not being able to connect to gfsh from outside 
AWS.

I started a locator in AWS with the following command:
{noformat}
gfsh>start locator --name=locator 
--J=-Dgemfire.jmx-manager-hostname-for-clients= 
--hostname-for-clients=
{noformat}

When trying to connect to this locator from my laptop I get the following error:
{noformat}
gfsh>connect --locator=52.41.104.182[10334]
Connecting to Locator at [host=52.41.104.182, port=10334] ..
Connecting to Manager at 
[host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, port=1099] ..
Could not connect to : [host=ec2-52-41-104-182.us-west-2.compute.amazonaws.com, 
port=1099]. Failed to retrieve RMIServer stub: 
javax.naming.CommunicationException [Root exception is 
java.rmi.ConnectIOException: error during JRMP connection establishment; nested 
exception is:
java.net.SocketException: Connection reset]
{noformat}
Note that gfsh is trying to connect to the public dns for the instance, not 
using the {{jmx-manager-hostname-for-clients}} property provided.



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

[jira] [Reopened] (GEODE-1521) APP_FETCH_SIZE in GFSH should not be applied to COUNT queries

[Kevin Duling (JIRA)]

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

Kevin Duling reopened GEODE-1521:
-

Re-opening so it can be added to Pivotal Tracker.

> APP_FETCH_SIZE in GFSH should not be applied to COUNT queries
> -
>
> Key: GEODE-1521
> URL: https://issues.apache.org/jira/browse/GEODE-1521
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Kevin Duling
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> There are more varieties of count than simply * within the count().  
> Specifically, one can do:  {{count(distinct(field))}} or {{count(field)}}
> This makes checking for only {{count( * )}} incorrect.  Instead, the search 
> to apply the limt should look for {{" count("}}



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

[jira] [Reopened] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available

[Kevin Duling (JIRA)]

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

Kevin Duling reopened GEODE-68:
---

Re-opening so it can be added to Pivotal Tracker.

> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: gfsh
> Fix For: 1.0.0-incubating.M3
>
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.  
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- | 
> --
> APP_COLLECTION_LIMIT   | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS   | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE   | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME   | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER  | basic
> SYS_CLASSPATH  | 
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME  | wmarkito
> SYS_JAVA_VERSION   | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR  |
> SYS_USER   | wmarkito
> SYS_USER_HOME  | /Users/wmarkito
> {code}



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

[jira] [Reopened] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH

[Kevin Duling (JIRA)]

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

Kevin Duling reopened GEODE-744:


Re-opening so it can be added to Pivotal Tracker.

> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from 
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the 
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and, 
> afterwards, executes two queries, one using lower case and other using upper 
> case. You can see from the console that ouput is different, one returns the 
> actual size (1500) and the other one returns the default APP_FETCH_SIZE 
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner 
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to 
> compare strings without using the actual word case. Is not enough to add more 
> "or" to the comparison like we are currently doing with since keywords like 
> "Count" or "coUn" will still break the functionallity. We should compare 
> everything using lower case or upper case, it doesn't matter which one, or at 
> least make sure that gfsh converts the query to upper/lower case before 
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT")  query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}



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

[jira] [Resolved] (GEODE-745) include-locators in shutdown command is ignored

[Kirk Lund (JIRA)]

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

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

> include-locators in shutdown command is ignored
> ---
>
> Key: GEODE-745
> URL: https://issues.apache.org/jira/browse/GEODE-745
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin)
>Reporter: Jens Deppe
>Assignee: Grace Meilen
> Fix For: 1.0.0-incubating.M3
>
>
> The management REST API endpoint for shutdown, does not accept the 
> include-locators parameter, and hence does not shutdown the locators.
> To reproduce connect to cluster using http:
> {noformat}
> gfsh
> connect --use-http --url=...
> shutdown --include-locators=true
> {noformat}
> Observe that the locators are not shutdown.



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

[jira] [Updated] (GEODE-745) include-locators in shutdown command is ignored

[Kirk Lund (JIRA)]

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

Kirk Lund updated GEODE-745:

Assignee: Grace Meilen

> include-locators in shutdown command is ignored
> ---
>
> Key: GEODE-745
> URL: https://issues.apache.org/jira/browse/GEODE-745
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin)
>Reporter: Jens Deppe
>Assignee: Grace Meilen
>
> The management REST API endpoint for shutdown, does not accept the 
> include-locators parameter, and hence does not shutdown the locators.
> To reproduce connect to cluster using http:
> {noformat}
> gfsh
> connect --use-http --url=...
> shutdown --include-locators=true
> {noformat}
> Observe that the locators are not shutdown.



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

[jira] [Commented] (GEODE-1530) geode-examples setEnv.sh script needs to export path

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

https://github.com/apache/incubator-geode/pull/158

GEODE-1530: geode-examples setEnv.sh script needs to export path

Without an export of the path, using the GEODE_HOME env variable,
the scripts/startAll.sh script will pick up the first gfsh in the
path that it finds.

Also updated the scripts/stopAll.sh script to run the setEnv.sh
script, so that stopAll.sh uses the correct gfsh.

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

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

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

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


commit 1983f9d6969e6e2e051cbda69d908b871812bbab
Author: Karen Miller 
Date:   2016-06-15T18:07:03Z

GEODE-1530: geode-examples setEnv.sh script needs to export path

Without an export of the path, using the GEODE_HOME env variable,
the scripts/startAll.sh script will pick up the first gfsh in the
path that it finds.

Also updated the scripts/stopAll.sh script to run the setEnv.sh
script, so that stopAll.sh uses the correct gfsh.




> geode-examples setEnv.sh script needs to export path
> 
>
> Key: GEODE-1530
> URL: https://issues.apache.org/jira/browse/GEODE-1530
> Project: Geode
>  Issue Type: Bug
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>  Labels: bug-hunt
>
> Work currently on the feature/GEODE-33 branch.
> In the replicated example, the {{scripts/setEnv.sh}} script should to prepend 
> the {{GEODE_HOME}} environment variable it finds to the PATH, so that the 
> {{startAll.sh}} uses that path.
> Append this line to the {{scripts/setEnv.sh}} script:
> {{export PATH=$GEODE_HOME/bin:$PATH}}



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

[jira] [Resolved] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

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

Dave Barnes resolved GEODE-1547.

Resolution: Fixed

Update deployed

> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: web-content
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit 8bf10a5e849f41c1e552cb440a2d5e713e5e2332 in incubator-geode's branch 
refs/heads/feature/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=8bf10a5 ]

GEODE-1372 added .rej and .orig filter for rat and gitignore

Fixed header in GMSEncryptJunitTest. Fixed compilation error in Lucene test


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-1547) Add new committer to website

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1547:


Commit 791a418b650c20c8c7d94fb25b85ab7cb93e9d55 in incubator-geode's branch 
refs/heads/asf-site from [~dbarnes97]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=791a418b ]

GEODE-1547: Deploy website updates


> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: web-content
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Commented] (GEODE-1209) Support/Propagating eviction and expiration operation with AsycEventQueue.

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade commented on GEODE-1209:
--

Found a critical product bug, that impacts this feature. Created a new product 
bug GEODE-1472.
Sent new proposal to community with supporting only expiration-destroy events 
for now.
After feedback from community started adding/modifying the changes to support 
forwarding expiration destroy events.

> Support/Propagating eviction and expiration operation with AsycEventQueue.
> --
>
> Key: GEODE-1209
> URL: https://issues.apache.org/jira/browse/GEODE-1209
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>
> The AsyncEventQueue works as a write-behind cache event handler to 
> synchronize region updates with other source...Currently it does not support 
> distribution of eviction or expiration operationThis makes the external 
> source to be out of sync with data that has been removed/invalidated through 
> eviction and expiration.
> This ticket is to add/support eviction and expiration operation with 
> AsyncEventQueue, so that all the operations are propagated to 
> AsyncEventQueueListener and the usage of those events are left to underlying 
> implementation/applications(like WAN, Lucene, plug-able storage, etc).
> http://gemfire.docs.pivotal.io/docs-gemfire/latest/developing/events/implementing_write_behind_event_handler.html#implementing_write_behind_cache_event_handling



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

[jira] [Assigned] (GEODE-1209) Support/Propagating eviction and expiration operation with AsycEventQueue.

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade reassigned GEODE-1209:


Assignee: Anilkumar Gingade

> Support/Propagating eviction and expiration operation with AsycEventQueue.
> --
>
> Key: GEODE-1209
> URL: https://issues.apache.org/jira/browse/GEODE-1209
> Project: Geode
>  Issue Type: Bug
>  Components: docs, wan
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>
> The AsyncEventQueue works as a write-behind cache event handler to 
> synchronize region updates with other source...Currently it does not support 
> distribution of eviction or expiration operationThis makes the external 
> source to be out of sync with data that has been removed/invalidated through 
> eviction and expiration.
> This ticket is to add/support eviction and expiration operation with 
> AsyncEventQueue, so that all the operations are propagated to 
> AsyncEventQueueListener and the usage of those events are left to underlying 
> implementation/applications(like WAN, Lucene, plug-able storage, etc).
> http://gemfire.docs.pivotal.io/docs-gemfire/latest/developing/events/implementing_write_behind_event_handler.html#implementing_write_behind_cache_event_handling



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

[jira] [Assigned] (GEODE-1493) config/gemfire.properties that is shipped with the geode distribution contains user specific info

[Sai Boorlagadda (JIRA)]

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

Sai Boorlagadda reassigned GEODE-1493:
--

Assignee: Sai Boorlagadda

> config/gemfire.properties that is shipped with the geode distribution 
> contains user specific info
> -
>
> Key: GEODE-1493
> URL: https://issues.apache.org/jira/browse/GEODE-1493
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Sai Boorlagadda
> Fix For: 1.0.0-incubating.M3
>
>
> The geode-assembly/build.gradle file generates a default gemfire.properties 
> and cache.xml that get included in the config directory in the binary 
> distribution. See the defaultDistributionConfig target.
> However, the generated gemfire.properties file has a bad value for 
> cluster-configuration-dir. This is the value that shipped with M2:
> {noformat}
> cluster-configuration-dir=/home/dsmith/data/work/gemfire5/open/geode-assembly/build
> {noformat}
> The mcast-address is also suspect, because the default mcast address depends 
> on whether the build system system prefers IPv6 or IPv4 addresses.



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

[jira] [Commented] (GEODE-1542) shared/unordered tcp/ip connection times out, initiating suspicion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1542:


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

GEODE-1542: Removing a bogus static import of javafx class

This class picked up a bad import of a javafx class. With openjdk this
causes compile errors.


> shared/unordered tcp/ip connection times out, initiating suspicion
> --
>
> Key: GEODE-1542
> URL: https://issues.apache.org/jira/browse/GEODE-1542
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.0.0-incubating.M3
>
>
> I recently diagnosed a membership failure that was initiated when one member 
> (N) timed out its shared/unordered tcp/ip connection to another member (M).  
> Member M initiated suspect processing that lead to kicking member N out of 
> the system.  We need to either stop timing out shared/unordered connections 
> or have an orderly shutdown mechanism so that we don't initiate suspect 
> processing.
> The final-check that M performed showed something odd.  Member N never logged 
> that it processed a final check from M.  Member M logged that it had 
> connected to N and read a status byte from it.  The byte had the value 21, 
> which is not a valid response to a final check (it should be 0 or 0x7B).
> {noformat}
> Received [21, ent(clientgemfire3_ent_19225:19225):1028]
> {noformat}
> I verified that M used the correct tcp/ip port for N, so this is very odd and 
> needs to be investigated.



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-11: Support indexing values that are Strings or Numbers

Adding support to index values that are strings or numbers, by providing
a special field name LuceneIndex.REGION_VALUE_FIELD that indicates the
entire value should be indexed.


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-1421) CI Failure: MemoryThresholdsDUnitTest.testDRLoadRejection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1421:


Commit cdfb9401cff5b86ebcf8fb424bb36139bba36a91 in incubator-geode's branch 
refs/heads/feature/GEODE-93 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=cdfb940 ]

GEODE-1421: improve test to provide more info on failure

I ran the test 1000 times and they all passed.
Assertions are now done on the member that does
the get that should have also stored the entry
in the cache.


> CI Failure: MemoryThresholdsDUnitTest.testDRLoadRejection
> -
>
> Key: GEODE-1421
> URL: https://issues.apache.org/jira/browse/GEODE-1421
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Sai Boorlagadda
>Assignee: Darrel Schneider
>  Labels: CI
> Fix For: 1.0.0-incubating.M3
>
>
> {noformat}
> Error Message
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest$68.run in VM 
> 2 running on Host venezuela.gemstone.com with 4 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest$68.run in VM 
> 2 running on Host venezuela.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest.testDRLoadRejection(MemoryThresholdsDUnitTest.java:2019)
>   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.GeneratedMethodAccessor369.invoke(Unknown Source)
>   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.GeneratedMethodAccessor368.invoke(Unknown Source)
>   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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> 

[jira] [Commented] (GEODE-1545) add a test case for query JSON object in geode-lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1545:


Commit 0d5de3e3f5e69f4de683ea289ac58d36280f7d6d in incubator-geode's branch 
refs/heads/feature/GEODE-93 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0d5de3e ]

GEODE-1545: fix compile problem caused by merge


> add a test case for query JSON object in geode-lucene
> -
>
> Key: GEODE-1545
> URL: https://issues.apache.org/jira/browse/GEODE-1545
> Project: Geode
>  Issue Type: Test
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> We did support query on JSON object, but we don't have a test yet. 



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

[jira] [Commented] (GEODE-1470) Upgrade log4j to 2.6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1470:


Commit 0f2bb8fa713d391b59cb5e3f8e8641194bb915e9 in incubator-geode's branch 
refs/heads/feature/GEODE-93 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0f2bb8f ]

GEODE-1470: Upgrade log4j to 2.6.1

* This closes #154 [kl...@apache.org]


> Upgrade log4j to 2.6
> 
>
> Key: GEODE-1470
> URL: https://issues.apache.org/jira/browse/GEODE-1470
> Project: Geode
>  Issue Type: Improvement
>  Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> The new version of log4j (2.6) has made improvements to make it "garbage 
> free" (source: https://www.infoq.com/news/2016/05/log4j-garbage-free). We 
> should upgrade to this version to reap the benefits.



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

Commit 79cba4dcb7c28256fa17569956c8143f58388b65 in incubator-geode's branch 
refs/heads/feature/GEODE-93 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=79cba4d ]

GEODE-11: Change from MultiFieldQueryParser to StandardQueryParser


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-1545) add a test case for query JSON object in geode-lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1545:


Commit ed32ceefba89b5cd295659faa3368971ee4adabb in incubator-geode's branch 
refs/heads/feature/GEODE-93 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ed32cee ]

GEODE-1545: add a test case for querying JSON in geode-lucene


> add a test case for query JSON object in geode-lucene
> -
>
> Key: GEODE-1545
> URL: https://issues.apache.org/jira/browse/GEODE-1545
> Project: Geode
>  Issue Type: Test
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> We did support query on JSON object, but we don't have a test yet. 



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

Commit d5dae19b2d595403ddc1d2344e5fa3cf0bbc32a6 in incubator-geode's branch 
refs/heads/feature/GEODE-93 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d5dae19 ]

GEODE-11: Passing down defaultField to query parser


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

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

Dave Barnes commented on GEODE-1547:


Two steps:
1. Edit Committer's list & commit.
2. Build site & deploy (asf-site branch).

Step 1 complete: checked in on 'develop'. (Minor changes to the site, in the 
past, have been made without going through git flow protocol of feature 
branches and reviews, so I followed that pattern.)


> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: web-content
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Commented] (GEODE-1547) Add new committer to website

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1547:


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

GEODE-1547: Added Nabarun Nag to list of committers on website's Community 
page, reformatted list so columns balance


> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: web-content
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Updated] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-1547:
---
Component/s: (was: docs)
 web-content

> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: web-content
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Assigned] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

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

Dave Barnes reassigned GEODE-1547:
--

Assignee: Dave Barnes

> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Updated] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

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

Dave Barnes updated GEODE-1547:
---
Component/s: docs

> Add new committer to website
> 
>
> Key: GEODE-1547
> URL: https://issues.apache.org/jira/browse/GEODE-1547
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Dave Barnes
>Assignee: Dave Barnes
>Priority: Minor
>
> Add Nabarun Nag to the list of committers on the Geode website's Community 
> page. Build and deploy the updated site.



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

[jira] [Created] (GEODE-1547) Add new committer to website

[Dave Barnes (JIRA)]

Dave Barnes created GEODE-1547:
--

 Summary: Add new committer to website
 Key: GEODE-1547
 URL: https://issues.apache.org/jira/browse/GEODE-1547
 Project: Geode
  Issue Type: Improvement
Reporter: Dave Barnes


Add Nabarun Nag to the list of committers on the Geode website's Community 
page. Build and deploy the updated site.



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

[jira] [Commented] (GEODE-1543) Not using the the correct log level when exceptions are thrown while creating indexes.

[ASF GitHub Bot (JIRA)]

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

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

GitHub user nabarunnag reopened a pull request:

https://github.com/apache/incubator-geode/pull/156

GEODE-1543: Change the log level from error to info

* When multiple peers join the cluster conncurrently, only the first one 
that joins will distribute the index creation and other will try to create the 
index locally because of the distributed message and then log an error 
afterwards.
* This is an expected behaviour and hence should not be logged as error but 
rather as a info.

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

$ git pull https://github.com/nabarunnag/incubator-geode feature/GEODE-1543

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

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


commit 3af0fbb8944010e7c890e0817037568c7bca157d
Author: nabarun 
Date:   2016-06-13T19:04:50Z

GEODE-1543: Change the log level from error to info

* When multiple peers join the cluster conncurrently, only the first one 
that joins will distribute the index creation and other will try to create the 
index locally because of the distributed message and then log an error 
afterwards.
* This is an expected behaviour and hence should not be logged as error but 
rather as a info.




> Not using the the correct log level when exceptions are thrown while creating 
> indexes.
> --
>
> Key: GEODE-1543
> URL: https://issues.apache.org/jira/browse/GEODE-1543
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> When two or more peers join the cluster concurrently, only the first one that 
> joins will distribute the index creation while reading its cache.xml file, 
> the rest will create the index locally due to the distributed message and log 
> an error afterwards, while trying to create the index from its own cache.xml 
> file. This error message is currently being registered under "ERROR" log 
> level, and it should be registered under "WARNING", or even not be registered 
> at all since this "exception" is expected during startup (we could easily 
> cache the indexes created locally by other distributed members)
> {noformat}
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Index creation message got the pr Partitioned Region 
> @57fd91c9 [path='/ClientSessionRegionPosSrv'; dataPolicy=PARTITION; 
> gatewayEnabled=false; prId=1; isDestroyed=false; isClosed=false; 
> retryTimeout=360; serialNumber=7; partition 
> attributes=PartitionAttributes@1828508781[redundantCopies=1;localMaxMemory=5;totalMaxMemory=2147483647;totalNumBuckets=47;partitionResolver=null;colocatedWith=null;recoveryDelay=30;startupRecoveryDelay=6;FixedPartitionAttributes=null;partitionListeners=null];
>  on VM 10.69.252.112(host1-server2:21655):34609]
> [fine 2016/05/12 09:37:01.744 BST host1-server2  tid=0x1] 
> LocalRegion.createOQLIndexes on region /ClientSessionRegionPosSrv
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Processing index creation message on this remote 
> partitioned region vm for indexes: ClientSessionRegionPosSrv.byUser 
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Started creating index with Index Name 
> :ClientSessionRegionPosSrv.byUser On PartitionedRegion 
> /ClientSessionRegionPosSrv, Indexfrom caluse=/ClientSessionRegionPosSrv, 
> Remote Request: true
> [fine 2016/05/12 09:37:01.744 BST host1-server2  tid=0x1] QueryService 
> Index creation process for {}ClientSessionRegionPosSrv.byUser
> [fine 2016/05/12 09:37:01.750 BST host1-server2  Processor1> tid=0x44] Completed creating index with Index Name 
> :ClientSessionRegionPosSrv.byUser On PartitionedRegion 
> /ClientSessionRegionPosSrv, Remote Request: true
> [fine 2016/05/12 09:37:01.751 BST host1-server2  Processor1> tid=0x44] Multi Index creation completed on remote host and has 
> sent the reply to the originating vm.
> [fine 2016/05/12 09:37:01.769 BST host1-server2  tid=0x1] Started 
> creating index with Index Name :ClientSessionRegionPosSrv.byUser On 
> PartitionedRegion /ClientSessionRegionPosSrv, Indexfrom 
> caluse=/ClientSessionRegionPosSrv, Remote Request: false
> [error 2016/05/12 09:37:01.770 BST host1-server2  tid=0x1] Failed to 
> create index ClientSessionRegionPosSrv.byUser on region 
> /ClientSessionRegionPosSrv with exception: 
> com.gemstone.gemfire.cache.query.IndexNameConflictException: Index named ' 
> 

[jira] [Commented] (GEODE-1543) Not using the the correct log level when exceptions are thrown while creating indexes.

[ASF GitHub Bot (JIRA)]

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

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

Github user nabarunnag closed the pull request at:

https://github.com/apache/incubator-geode/pull/156


> Not using the the correct log level when exceptions are thrown while creating 
> indexes.
> --
>
> Key: GEODE-1543
> URL: https://issues.apache.org/jira/browse/GEODE-1543
> Project: Geode
>  Issue Type: Bug
>Reporter: nabarun
>
> When two or more peers join the cluster concurrently, only the first one that 
> joins will distribute the index creation while reading its cache.xml file, 
> the rest will create the index locally due to the distributed message and log 
> an error afterwards, while trying to create the index from its own cache.xml 
> file. This error message is currently being registered under "ERROR" log 
> level, and it should be registered under "WARNING", or even not be registered 
> at all since this "exception" is expected during startup (we could easily 
> cache the indexes created locally by other distributed members)
> {noformat}
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Index creation message got the pr Partitioned Region 
> @57fd91c9 [path='/ClientSessionRegionPosSrv'; dataPolicy=PARTITION; 
> gatewayEnabled=false; prId=1; isDestroyed=false; isClosed=false; 
> retryTimeout=360; serialNumber=7; partition 
> attributes=PartitionAttributes@1828508781[redundantCopies=1;localMaxMemory=5;totalMaxMemory=2147483647;totalNumBuckets=47;partitionResolver=null;colocatedWith=null;recoveryDelay=30;startupRecoveryDelay=6;FixedPartitionAttributes=null;partitionListeners=null];
>  on VM 10.69.252.112(host1-server2:21655):34609]
> [fine 2016/05/12 09:37:01.744 BST host1-server2  tid=0x1] 
> LocalRegion.createOQLIndexes on region /ClientSessionRegionPosSrv
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Processing index creation message on this remote 
> partitioned region vm for indexes: ClientSessionRegionPosSrv.byUser 
> [fine 2016/05/12 09:37:01.744 BST host1-server2  Processor1> tid=0x44] Started creating index with Index Name 
> :ClientSessionRegionPosSrv.byUser On PartitionedRegion 
> /ClientSessionRegionPosSrv, Indexfrom caluse=/ClientSessionRegionPosSrv, 
> Remote Request: true
> [fine 2016/05/12 09:37:01.744 BST host1-server2  tid=0x1] QueryService 
> Index creation process for {}ClientSessionRegionPosSrv.byUser
> [fine 2016/05/12 09:37:01.750 BST host1-server2  Processor1> tid=0x44] Completed creating index with Index Name 
> :ClientSessionRegionPosSrv.byUser On PartitionedRegion 
> /ClientSessionRegionPosSrv, Remote Request: true
> [fine 2016/05/12 09:37:01.751 BST host1-server2  Processor1> tid=0x44] Multi Index creation completed on remote host and has 
> sent the reply to the originating vm.
> [fine 2016/05/12 09:37:01.769 BST host1-server2  tid=0x1] Started 
> creating index with Index Name :ClientSessionRegionPosSrv.byUser On 
> PartitionedRegion /ClientSessionRegionPosSrv, Indexfrom 
> caluse=/ClientSessionRegionPosSrv, Remote Request: false
> [error 2016/05/12 09:37:01.770 BST host1-server2  tid=0x1] Failed to 
> create index ClientSessionRegionPosSrv.byUser on region 
> /ClientSessionRegionPosSrv with exception: 
> com.gemstone.gemfire.cache.query.IndexNameConflictException: Index named ' 
> ClientSessionRegionPosSrv.byUser ' already exists.
> {noformat}



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit b27967a3e0c15f9f2e0769314f5581ef7c847faa in incubator-geode's branch 
refs/heads/feature/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=b27967a ]

GEODE-1372 Updated analyzeSerializable test and headers.

Fixed junit failure for FindCoordinatorrequest.


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-1545) add a test case for query JSON object in geode-lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1545:


Commit ed32ceefba89b5cd295659faa3368971ee4adabb in incubator-geode's branch 
refs/heads/GEODE-1372 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ed32cee ]

GEODE-1545: add a test case for querying JSON in geode-lucene


> add a test case for query JSON object in geode-lucene
> -
>
> Key: GEODE-1545
> URL: https://issues.apache.org/jira/browse/GEODE-1545
> Project: Geode
>  Issue Type: Test
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> We did support query on JSON object, but we don't have a test yet. 



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit b27967a3e0c15f9f2e0769314f5581ef7c847faa in incubator-geode's branch 
refs/heads/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=b27967a ]

GEODE-1372 Updated analyzeSerializable test and headers.

Fixed junit failure for FindCoordinatorrequest.


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-1542) shared/unordered tcp/ip connection times out, initiating suspicion

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1542:


Commit 33ceb371554a13c7643ddaf9488ffa83963de1e7 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~bschuchardt]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=33ceb37 ]

GEODE-1542 shared/unordered tcp/ip connection times out, initiating suspicion

This disables timing out of shared/unordered TcpConduit connections.  We don't
want them to time out because we are using them to initiate suspect processing
on other members.

The ticket also pointed out a problem with the "final check" mechanism in
the health monitor.  I tracked that down to improper use of SocketCreator
to create the server-socket in GMSHealthMonitor.  It was creating sn SSL
socket if SSL is enabled but the client-side of the check uses non-SSL
sockets.  I changed the server to use non-SSL sockets as well since no
useful information is sent over the final-check TCP/IP connections & they
need to be lightweight and fast.

While looking at logs I also found that the heartbeat request sent at the
beginning of a final-check had a request-ID even though it's not waiting
for a response.  That causes processing of the response to do more work
than necessary so I changed it to remove the request-ID from the message.


> shared/unordered tcp/ip connection times out, initiating suspicion
> --
>
> Key: GEODE-1542
> URL: https://issues.apache.org/jira/browse/GEODE-1542
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Reporter: Bruce Schuchardt
> Fix For: 1.0.0-incubating.M3
>
>
> I recently diagnosed a membership failure that was initiated when one member 
> (N) timed out its shared/unordered tcp/ip connection to another member (M).  
> Member M initiated suspect processing that lead to kicking member N out of 
> the system.  We need to either stop timing out shared/unordered connections 
> or have an orderly shutdown mechanism so that we don't initiate suspect 
> processing.
> The final-check that M performed showed something odd.  Member N never logged 
> that it processed a final check from M.  Member M logged that it had 
> connected to N and read a status byte from it.  The byte had the value 21, 
> which is not a valid response to a final check (it should be 0 or 0x7B).
> {noformat}
> Received [21, ent(clientgemfire3_ent_19225:19225):1028]
> {noformat}
> I verified that M used the correct tcp/ip port for N, so this is very odd and 
> needs to be investigated.



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit 571724bb555db9d54699f7f6b469530c52c51389 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=571724b ]

GEODE-1362 Merge remote-tracking branch 'origin/develop' into feature/GEODE-1372

Conflicts:

geode-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystemConfigProperties.java

geode-core/src/test/java/com/gemstone/gemfire/cache30/DistributedMulticastRegionDUnitTest.java

geode-core/src/test/java/com/gemstone/gemfire/distributed/LocatorDUnitTest.java

geode-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessengerJUnitTest.java


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

Commit 79cba4dcb7c28256fa17569956c8143f58388b65 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=79cba4d ]

GEODE-11: Change from MultiFieldQueryParser to StandardQueryParser


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit 28c253fcf19d4c44e4f7ac896cfb8685deeb1eb4 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=28c253f ]

GEODE-1372 DS property name change and junit fix


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1372:


Commit df2dfe731012743801618d09a208cd47965df54f in incubator-geode's branch 
refs/heads/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=df2dfe7 ]

GEODE-1372 removing this file


> Geode UDP communications are not secure when SSL is configured
> --
>
> Key: GEODE-1372
> URL: https://issues.apache.org/jira/browse/GEODE-1372
> Project: Geode
>  Issue Type: New Feature
>  Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Hitesh Khamesra
>
> Gemfire servers use UDP requests to communicate membership views, suspect 
> processing and other information. When gemfire SSL is enabled, only the TCP 
> requests are encrypted and UDP requests are not.



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

[jira] [Commented] (GEODE-1362) CI failure: ListIndexCommandDUnitTest.testListIndex

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1362:


Commit 571724bb555db9d54699f7f6b469530c52c51389 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~hitesh.khamesra]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=571724b ]

GEODE-1362 Merge remote-tracking branch 'origin/develop' into feature/GEODE-1372

Conflicts:

geode-core/src/main/java/com/gemstone/gemfire/distributed/DistributedSystemConfigProperties.java

geode-core/src/test/java/com/gemstone/gemfire/cache30/DistributedMulticastRegionDUnitTest.java

geode-core/src/test/java/com/gemstone/gemfire/distributed/LocatorDUnitTest.java

geode-core/src/test/java/com/gemstone/gemfire/distributed/internal/membership/gms/messenger/JGroupsMessengerJUnitTest.java


> CI failure: ListIndexCommandDUnitTest.testListIndex
> ---
>
> Key: GEODE-1362
> URL: https://issues.apache.org/jira/browse/GEODE-1362
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Hitesh Khamesra
>Assignee: Jinmei Liao
>  Labels: CI
>
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.management.internal.cli.commands.ListIndexCommandDUnitTest$2.run
>  in VM 1 running on Host timor.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.ListIndexCommandDUnitTest$Peer.run(ListIndexCommandDUnitTest.java:355)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.ListIndexCommandDUnitTest.loadConsumerData(ListIndexCommandDUnitTest.java:185)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.ListIndexCommandDUnitTest.setupGemFire(ListIndexCommandDUnitTest.java:133)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.ListIndexCommandDUnitTest.postSetUpCliCommandTestBase(ListIndexCommandDUnitTest.java:78)
>   at 
> com.gemstone.gemfire.management.internal.cli.commands.CliCommandTestBase.postSetUp(CliCommandTestBase.java:79)
>   at 
> com.gemstone.gemfire.test.dunit.internal.JUnit4DistributedTestCase.setUp(JUnit4DistributedTestCase.java:354)
>   at sun.reflect.GeneratedMethodAccessor27.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
>   at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
>   at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
>   at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
>   at org.junit.rules.RunRules.evaluate(RunRules.java:20)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
>   at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
>   at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
>   at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
>   at 
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java: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.GeneratedMethodAccessor8.invoke(Unknown Source)
>   at 
> 

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

Commit d5dae19b2d595403ddc1d2344e5fa3cf0bbc32a6 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d5dae19 ]

GEODE-11: Passing down defaultField to query parser


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-1443) javadocs on PartitionResolver should mention callback arg

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1443:


Commit 4afc5b1531d1b10afd7f40beaa535a49abd22282 in incubator-geode's branch 
refs/heads/GEODE-1372 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=4afc5b1 ]

GEODE-1443: fix PartitionResolver javadocs

The javadocs now describes the third option of using
a callback argument as the PartitionResolver.


> javadocs on PartitionResolver should mention callback arg
> -
>
> Key: GEODE-1443
> URL: https://issues.apache.org/jira/browse/GEODE-1443
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> The external javadocs for PartitionResolver should mention the third way of 
> using a resolver which is to have a callback argument that implements the 
> interface. 
> The docs describe this here: 
> http://geode.docs.pivotal.io/docs/developing/partitioned_regions/using_custom_partition_resolvers.html



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

[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-68:
-

Github user kjduling closed the pull request at:

https://github.com/apache/incubator-geode/pull/152


> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: gfsh
> Fix For: 1.0.0-incubating.M3
>
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.  
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- | 
> --
> APP_COLLECTION_LIMIT   | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS   | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE   | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME   | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER  | basic
> SYS_CLASSPATH  | 
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME  | wmarkito
> SYS_JAVA_VERSION   | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR  |
> SYS_USER   | wmarkito
> SYS_USER_HOME  | /Users/wmarkito
> {code}



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

[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-68:
-

Github user kjduling commented on the issue:

https://github.com/apache/incubator-geode/pull/152
  
Resubmitting due to Travis failure.


> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
>  Labels: gfsh
> Fix For: 1.0.0-incubating.M3
>
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.  
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- | 
> --
> APP_COLLECTION_LIMIT   | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS   | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE   | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME   | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER  | basic
> SYS_CLASSPATH  | 
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME  | wmarkito
> SYS_JAVA_VERSION   | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR  |
> SYS_USER   | wmarkito
> SYS_USER_HOME  | /Users/wmarkito
> {code}



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

[jira] [Commented] (GEODE-11) Lucene Integration

[ASF subversion and git services (JIRA)]

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

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

Commit d5dae19b2d595403ddc1d2344e5fa3cf0bbc32a6 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~huynhja]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d5dae19 ]

GEODE-11: Passing down defaultField to query parser


> Lucene Integration
> --
>
> Key: GEODE-11
> URL: https://issues.apache.org/jira/browse/GEODE-11
> Project: Geode
>  Issue Type: New Feature
>  Components: querying
>Reporter: Dan Smith
>Assignee: xiaojian zhou
>
> This is a feature that has been under development for GemFire but was not 
> part of the initial drop of code for geode.
> Allow Lucene indexes to be stored in Geode regions allowing users to do text 
> searches on data stored in Geode. 



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

[jira] [Commented] (GEODE-420) locator ssl configuration

[ASF subversion and git services (JIRA)]

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

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

Commit 57901ec6664737bc577efa6ae1e7a0689e1680a4 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=57901ec ]

GEODE-420: Fixing Tests


> locator ssl configuration
> -
>
> Key: GEODE-420
> URL: https://issues.apache.org/jira/browse/GEODE-420
> Project: Geode
>  Issue Type: New Feature
>  Components: locator
>Reporter: Darrel Schneider
>Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, 
> jmx-manager, and http-service.
> The "server" attributes configure the ssl connections from clients to a cache 
> server.
> The "gateway" attributes configure the ssl connections between a gateway 
> sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin 
> client (for example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST 
> clients and the http-service.
> The "cluster" attributes configure the ssl connections between the members of 
> a distributed system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running 
> on your private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all 
> using unsecure connections.
> But some of these members are hosting a cache server and have clients 
> connecting to them. So you configure "server" ssl for the client to server 
> connections. But for your clients to find you servers they need to talk to 
> the locator. Since the clients are coming from the outside world you want 
> them to use SSL. So you configure "server" ssl on them for when they connect 
> to the cache server and "cluster" SSL on them for when they connect to the 
> locator. But your locators are configured with "cluster" SSL disabled so that 
> the p2p connects on the internal network will not be SSL.
> So you are either forced to have you client to locator connections to be 
> unsecure or you need to secure all the cluster connections forcing the peers 
> to also use SSL.
> I think we should introduce "locator" SSL configuration options that would 
> allow you to have just the locator and server using SSL and the "cluster" to 
> have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for 
> clients but non-SSL for locator-to-locator and peers-to-locator connections. 
> I think this would be more complicated because we would need to have 
> different ports that the locator listens on (one for clients and one for 
> locators and members).
>  



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

[jira] [Commented] (GEODE-420) locator ssl configuration

[ASF subversion and git services (JIRA)]

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

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

Commit 12f69bed22a29c7b23b7299d71f776ea36fa7ed1 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=12f69be ]

GEODE-420: Added SSLEnabledComponents.java


> locator ssl configuration
> -
>
> Key: GEODE-420
> URL: https://issues.apache.org/jira/browse/GEODE-420
> Project: Geode
>  Issue Type: New Feature
>  Components: locator
>Reporter: Darrel Schneider
>Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, 
> jmx-manager, and http-service.
> The "server" attributes configure the ssl connections from clients to a cache 
> server.
> The "gateway" attributes configure the ssl connections between a gateway 
> sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin 
> client (for example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST 
> clients and the http-service.
> The "cluster" attributes configure the ssl connections between the members of 
> a distributed system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running 
> on your private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all 
> using unsecure connections.
> But some of these members are hosting a cache server and have clients 
> connecting to them. So you configure "server" ssl for the client to server 
> connections. But for your clients to find you servers they need to talk to 
> the locator. Since the clients are coming from the outside world you want 
> them to use SSL. So you configure "server" ssl on them for when they connect 
> to the cache server and "cluster" SSL on them for when they connect to the 
> locator. But your locators are configured with "cluster" SSL disabled so that 
> the p2p connects on the internal network will not be SSL.
> So you are either forced to have you client to locator connections to be 
> unsecure or you need to secure all the cluster connections forcing the peers 
> to also use SSL.
> I think we should introduce "locator" SSL configuration options that would 
> allow you to have just the locator and server using SSL and the "cluster" to 
> have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for 
> clients but non-SSL for locator-to-locator and peers-to-locator connections. 
> I think this would be more complicated because we would need to have 
> different ports that the locator listens on (one for clients and one for 
> locators and members).
>  



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

[jira] [Commented] (GEODE-420) locator ssl configuration

[ASF subversion and git services (JIRA)]

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

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

Commit 806eacda90b618f5e76b032e268a657d269198e6 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=806eacd ]

GEODE-420: Removal of more deprecated properties and addition of new "alias" 
properties


> locator ssl configuration
> -
>
> Key: GEODE-420
> URL: https://issues.apache.org/jira/browse/GEODE-420
> Project: Geode
>  Issue Type: New Feature
>  Components: locator
>Reporter: Darrel Schneider
>Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, 
> jmx-manager, and http-service.
> The "server" attributes configure the ssl connections from clients to a cache 
> server.
> The "gateway" attributes configure the ssl connections between a gateway 
> sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin 
> client (for example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST 
> clients and the http-service.
> The "cluster" attributes configure the ssl connections between the members of 
> a distributed system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running 
> on your private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all 
> using unsecure connections.
> But some of these members are hosting a cache server and have clients 
> connecting to them. So you configure "server" ssl for the client to server 
> connections. But for your clients to find you servers they need to talk to 
> the locator. Since the clients are coming from the outside world you want 
> them to use SSL. So you configure "server" ssl on them for when they connect 
> to the cache server and "cluster" SSL on them for when they connect to the 
> locator. But your locators are configured with "cluster" SSL disabled so that 
> the p2p connects on the internal network will not be SSL.
> So you are either forced to have you client to locator connections to be 
> unsecure or you need to secure all the cluster connections forcing the peers 
> to also use SSL.
> I think we should introduce "locator" SSL configuration options that would 
> allow you to have just the locator and server using SSL and the "cluster" to 
> have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for 
> clients but non-SSL for locator-to-locator and peers-to-locator connections. 
> I think this would be more complicated because we would need to have 
> different ports that the locator listens on (one for clients and one for 
> locators and members).
>  



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

[jira] [Commented] (GEODE-1545) add a test case for query JSON object in geode-lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1545:


Commit ed32ceefba89b5cd295659faa3368971ee4adabb in incubator-geode's branch 
refs/heads/feature/GEODE-420 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ed32cee ]

GEODE-1545: add a test case for querying JSON in geode-lucene


> add a test case for query JSON object in geode-lucene
> -
>
> Key: GEODE-1545
> URL: https://issues.apache.org/jira/browse/GEODE-1545
> Project: Geode
>  Issue Type: Test
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> We did support query on JSON object, but we don't have a test yet. 



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

[jira] [Commented] (GEODE-420) locator ssl configuration

[ASF subversion and git services (JIRA)]

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

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

Commit b6480b74eeab955455c2d84ac354b4e2ab4693b0 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=b6480b7 ]

GEODE-420: Add localized strings


> locator ssl configuration
> -
>
> Key: GEODE-420
> URL: https://issues.apache.org/jira/browse/GEODE-420
> Project: Geode
>  Issue Type: New Feature
>  Components: locator
>Reporter: Darrel Schneider
>Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, 
> jmx-manager, and http-service.
> The "server" attributes configure the ssl connections from clients to a cache 
> server.
> The "gateway" attributes configure the ssl connections between a gateway 
> sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin 
> client (for example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST 
> clients and the http-service.
> The "cluster" attributes configure the ssl connections between the members of 
> a distributed system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running 
> on your private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all 
> using unsecure connections.
> But some of these members are hosting a cache server and have clients 
> connecting to them. So you configure "server" ssl for the client to server 
> connections. But for your clients to find you servers they need to talk to 
> the locator. Since the clients are coming from the outside world you want 
> them to use SSL. So you configure "server" ssl on them for when they connect 
> to the cache server and "cluster" SSL on them for when they connect to the 
> locator. But your locators are configured with "cluster" SSL disabled so that 
> the p2p connects on the internal network will not be SSL.
> So you are either forced to have you client to locator connections to be 
> unsecure or you need to secure all the cluster connections forcing the peers 
> to also use SSL.
> I think we should introduce "locator" SSL configuration options that would 
> allow you to have just the locator and server using SSL and the "cluster" to 
> have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for 
> clients but non-SSL for locator-to-locator and peers-to-locator connections. 
> I think this would be more complicated because we would need to have 
> different ports that the locator listens on (one for clients and one for 
> locators and members).
>  



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

[jira] [Commented] (GEODE-1545) add a test case for query JSON object in geode-lucene

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1545:


Commit 0d5de3e3f5e69f4de683ea289ac58d36280f7d6d in incubator-geode's branch 
refs/heads/feature/GEODE-420 from zhouxh
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0d5de3e ]

GEODE-1545: fix compile problem caused by merge


> add a test case for query JSON object in geode-lucene
> -
>
> Key: GEODE-1545
> URL: https://issues.apache.org/jira/browse/GEODE-1545
> Project: Geode
>  Issue Type: Test
>Reporter: xiaojian zhou
>Assignee: xiaojian zhou
>
> We did support query on JSON object, but we don't have a test yet. 



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

[jira] [Commented] (GEODE-1470) Upgrade log4j to 2.6

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1470:


Commit 0f2bb8fa713d391b59cb5e3f8e8641194bb915e9 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0f2bb8f ]

GEODE-1470: Upgrade log4j to 2.6.1

* This closes #154 [kl...@apache.org]


> Upgrade log4j to 2.6
> 
>
> Key: GEODE-1470
> URL: https://issues.apache.org/jira/browse/GEODE-1470
> Project: Geode
>  Issue Type: Improvement
>  Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> The new version of log4j (2.6) has made improvements to make it "garbage 
> free" (source: https://www.infoq.com/news/2016/05/log4j-garbage-free). We 
> should upgrade to this version to reap the benefits.



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

[jira] [Commented] (GEODE-1421) CI Failure: MemoryThresholdsDUnitTest.testDRLoadRejection

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-1421:


Commit cdfb9401cff5b86ebcf8fb424bb36139bba36a91 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=cdfb940 ]

GEODE-1421: improve test to provide more info on failure

I ran the test 1000 times and they all passed.
Assertions are now done on the member that does
the get that should have also stored the entry
in the cache.


> CI Failure: MemoryThresholdsDUnitTest.testDRLoadRejection
> -
>
> Key: GEODE-1421
> URL: https://issues.apache.org/jira/browse/GEODE-1421
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Sai Boorlagadda
>Assignee: Darrel Schneider
>  Labels: CI
> Fix For: 1.0.0-incubating.M3
>
>
> {noformat}
> Error Message
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest$68.run in VM 
> 2 running on Host venezuela.gemstone.com with 4 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest$68.run in VM 
> 2 running on Host venezuela.gemstone.com with 4 VMs
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
>   at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
>   at 
> com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest.testDRLoadRejection(MemoryThresholdsDUnitTest.java:2019)
>   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.GeneratedMethodAccessor369.invoke(Unknown Source)
>   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.GeneratedMethodAccessor368.invoke(Unknown Source)
>   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.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
>   at 
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
>   at 
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
>   at 
> 

[jira] [Commented] (GEODE-420) locator ssl configuration

[ASF subversion and git services (JIRA)]

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

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

Commit f71350a150f7ac90a6f3706bbcda97f5cecb23b1 in incubator-geode's branch 
refs/heads/feature/GEODE-420 from [~ukohlmeyer]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=f71350a ]

GEODE-420: Initial Alias defintion and removal of deprecated SSL-ENABLED 
properties


> locator ssl configuration
> -
>
> Key: GEODE-420
> URL: https://issues.apache.org/jira/browse/GEODE-420
> Project: Geode
>  Issue Type: New Feature
>  Components: locator
>Reporter: Darrel Schneider
>Assignee: Bruce Schuchardt
>
> We currently allow separate SSL configuration for cluster, server, gateway, 
> jmx-manager, and http-service.
> The "server" attributes configure the ssl connections from clients to a cache 
> server.
> The "gateway" attributes configure the ssl connections between a gateway 
> sender and receiver.
> The "jmx-manager" attributes configure the ssl connections between an admin 
> client (for example gfsh) and the jmx-manager.
> The "http-service" attributes configure the ssl connections between REST 
> clients and the http-service.
> The "cluster" attributes configure the ssl connections between the members of 
> a distributed system (peer-to-peer connections) AND to the locators.
> Using "cluster" for the connections to a locator can be a problem.
> Say you trust all your members of a distributed system since they are running 
> on your private network. So no need for ssl on the p2p connections.
> So you disable cluster-ssl. These means that your peers are locators are all 
> using unsecure connections.
> But some of these members are hosting a cache server and have clients 
> connecting to them. So you configure "server" ssl for the client to server 
> connections. But for your clients to find you servers they need to talk to 
> the locator. Since the clients are coming from the outside world you want 
> them to use SSL. So you configure "server" ssl on them for when they connect 
> to the cache server and "cluster" SSL on them for when they connect to the 
> locator. But your locators are configured with "cluster" SSL disabled so that 
> the p2p connects on the internal network will not be SSL.
> So you are either forced to have you client to locator connections to be 
> unsecure or you need to secure all the cluster connections forcing the peers 
> to also use SSL.
> I think we should introduce "locator" SSL configuration options that would 
> allow you to have just the locator and server using SSL and the "cluster" to 
> have SSL disabled.
> Something else to consider would be for the locator to be able to use SSL for 
> clients but non-SSL for locator-to-locator and peers-to-locator connections. 
> I think this would be more complicated because we would need to have 
> different ports that the locator listens on (one for clients and one for 
> locators and members).
>  



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

[jira] [Resolved] (GEODE-217) Update DUnit framework to JUnit 4

[Kirk Lund (JIRA)]

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

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

Defining custom Rules is not necessary. DUnit framework and all DUnit tests are 
fully upgraded to JUnit 4.

> Update DUnit framework to JUnit 4
> -
>
> Key: GEODE-217
> URL: https://issues.apache.org/jira/browse/GEODE-217
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.0.0-incubating.M3
>
>
> DUnit tests are currently limited to JUnit 3.8 syntax and functionality. 
> Geode developers would like to be able to use JUnit 4.0 syntax and 
> functionality including Rules.
> Given the large number of DUnit tests it's probably more feasible to 
> introduce a new DUnit framework in package com.gemstone.gemfire.test.dunit in 
> the gemfire-core project. Then DUnit tests can be migrated one at a time from 
> using the old implementation in package dunit.* to using the new one.



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

[jira] [Resolved] (GEODE-837) Jenkins is not picking up test results

[Kirk Lund (JIRA)]

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

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

> Jenkins is not picking up test results
> --
>
> Key: GEODE-837
> URL: https://issues.apache.org/jira/browse/GEODE-837
> Project: Geode
>  Issue Type: Bug
>  Components: build
>Reporter: Dan Smith
>Assignee: Kirk Lund
> Fix For: 1.0.0-incubating.M3
>
>
> After c5efb80518abc2a2c7390af1d46e7c5892801e55, where we stopped searching 
> for specific test names, jenkins is no longer reporting dunit test results.
> The tests are still being run, but the XML reports that jenkins uses are 
> empty.
> I tracked the issue down partially. It looks like what is happening is the 
> dunit tests are running and reporting results, but then when the integration 
> tests run, it generates new XML files that overrwrite the dunit results in 
> gemfire-core/build/test-results with files that look like this (see how there 
> are no test results reported)
> {noformat}
>  tests="0" skipped="0" failures="0" errors="0" timestamp="1970-01-01T00:00:00" 
> hostname="dsmith-virtual" time="0.0">
> {noformat}
> It looks like this has something to do with the junit category stuff. Unit 
> tests files aren't getting stomped on like this, but dunit test files are. 
> Perhaps something to do with the DistributedTestCase hierarchy.



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

[jira] [Commented] (GEODE-1452) Annotate disabled test methods with @Ignore

[Kirk Lund (JIRA)]

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

Kirk Lund commented on GEODE-1452:
--

Commit for GEODE-837 added @Ignore to many disabled tests. Need to sweep 
through all tests again to make sure everything has been annotated.

> Annotate disabled test methods with @Ignore
> ---
>
> Key: GEODE-1452
> URL: https://issues.apache.org/jira/browse/GEODE-1452
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>
> Some of the older tests have test methods which were disabled by renaming the 
> test method from JUnit 3 syntax to something like "public void _testMethod" 
> or "public void disabled_testMethod".
> Most of these tests were then updated to JUnit 4, but the disabled tests 
> remain without @Ignore or @Test annotations.
> We should annotate these test methods with @Ignore and @Test so they are 
> correctly counted as skipped tests. Tickets should then be filed to analyze 
> whether these tests should be fixed or deleted.



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

[jira] [Resolved] (GEODE-1504) Remove unused test classes

[Kirk Lund (JIRA)]

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

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

Commit for GEODE-837 removed this file:

* com/gemstone/gemfire/UnitTestDoclet.java

> Remove unused test classes
> --
>
> Key: GEODE-1504
> URL: https://issues.apache.org/jira/browse/GEODE-1504
> Project: Geode
>  Issue Type: Wish
>  Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.0.0-incubating.M3
>
>
> Remove these unused test classes from Geode:
> * com/gemstone/gemfire/JUnitTestSetup.java
> * com/gemstone/gemfire/TimingTestCase.java
> * com/gemstone/gemfire/UnitTestDoclet.java
> * 
> com/gemstone/gemfire/cache/query/functional/IndexUsageWithAliasAsProjAtrbt.java
>  (misnamed duplicate of IndexUsageWithAliasAsProjAtrbtJUnitTest.java)
> * com/gemstone/gemfire/pdx/VersionClassLoader.java



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

[jira] [Resolved] (GEODE-1516) IntelliJ and Eclipse formatter in geode /etc organize imports differently

[Kirk Lund (JIRA)]

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

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

> IntelliJ and Eclipse formatter in geode /etc organize imports differently
> -
>
> Key: GEODE-1516
> URL: https://issues.apache.org/jira/browse/GEODE-1516
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
> Fix For: 1.0.0-incubating.M3
>
>
> The IntelliJ and Eclipse formatters in geode /etc should organize imports 
> identically.



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

[jira] [Resolved] (GEODE-1470) Upgrade log4j to 2.6

[Kevin Duling (JIRA)]

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

Kevin Duling resolved GEODE-1470.
-
Resolution: Fixed

Pull request accepted.

> Upgrade log4j to 2.6
> 
>
> Key: GEODE-1470
> URL: https://issues.apache.org/jira/browse/GEODE-1470
> Project: Geode
>  Issue Type: Improvement
>  Components: logging
>Reporter: Swapnil Bawaskar
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> The new version of log4j (2.6) has made improvements to make it "garbage 
> free" (source: https://www.infoq.com/news/2016/05/log4j-garbage-free). We 
> should upgrade to this version to reap the benefits.



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