Build failed in Jenkins: Geode-nightly #847

2017-05-26 Thread Apache Jenkins Server
See 


Changes:

[bschuchardt] GEODE-2954 Old client gets null memberID in cache listener

[upthewaterspout] Undoing spark connector changes related to geode 1.2

[nnag] GEODE-2950: Adding validation checks on create lucene index parameter

[nnag] GEODE-2944: Added __REGION_VALUE_FIELD explanation to lucene create

[dbarnes] GEODE-2941 Update Pulse documentation

[jiliao] GEODE-2977: make group/name option values consistent

[lhughesgodfrey] GEODE-2993: Rethrow CacheClosedException from

[nnag] GEODE-2950: Updated error messages

[nnag] GEODE-2957: Lucene create index DEFAULT keyword added for

[eshu] GEODE-2939: Make sure bucket region initiate event tracker from the

--
[...truncated 238.56 KB...]

org.apache.geode.management.internal.cli.commands.LauncherLifecycleCommandsDUnitTest
 > testVersionTitleForStartServerAndLocator FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.test.dunit.rules.DistributedRestoreSystemProperties$1.run in 
VM 1 running on Host asf921.gq1.ygridcore.net with 4 VMs

Caused by:
java.rmi.ConnectException: Connection refused to host: 67.195.81.141; 
nested exception is: 
java.net.ConnectException: Connection refused (Connection 
refused)

Caused by:
java.net.ConnectException: Connection refused (Connection refused)

82 tests completed, 30 failed
:geode-assembly:distributedTest FAILED
:geode-assembly:flakyTest
:geode-assembly:integrationTest
:geode-benchmarks:jar
:geode-benchmarks:javadoc UP-TO-DATE
:geode-benchmarks:javadocJar
:geode-benchmarks:sourcesJar
:geode-benchmarks:signArchives SKIPPED
:geode-benchmarks:assemble
:geode-benchmarks:compileTestJava UP-TO-DATE
:geode-benchmarks:processTestResources UP-TO-DATE
:geode-benchmarks:testClasses UP-TO-DATE
:geode-benchmarks:checkMissedTests UP-TO-DATE
:geode-benchmarks:spotlessJavaCheck
:geode-benchmarks:spotlessCheck
:geode-benchmarks:test UP-TO-DATE
:geode-benchmarks:check
:geode-benchmarks:build
:geode-benchmarks:distributedTest UP-TO-DATE
:geode-benchmarks:flakyTest UP-TO-DATE
:geode-benchmarks:integrationTest UP-TO-DATE
:geode-common:assemble
:geode-common:compileTestJava
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:spotlessJavaCheck
:geode-common:spotlessCheck
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
:geode-common:flakyTest
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:spotlessJavaCheck
:geode-core:spotlessCheck
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:flakyTest
:geode-core:integrationTest

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

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

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

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

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

3559 tests completed, 3 failed, 166 skipped
:geode-core:integrationTest FAILED
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geo

[jira] [Commented] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
@galen-pivotal
Thank you very much. I confirmed the message sent to the dev mailing list.


> Add official Socket timeout parameter when connecting to servers/locators
> -
>
> Key: GEODE-2788
> URL: https://issues.apache.org/jira/browse/GEODE-2788
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Masaki Yamakawa
>Priority: Minor
>  Labels: patch
>
> When connecting from the client to the servers/locators, if the 
> servers/locators is not started, the connection can not be established and a 
> Socket timeout occurs.
> This timeout value is 59 seconds by default. This timeout value is too long. 
> This timeout value can be changed by specifying the unofficial parameter 
> "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I 
> corresponded so that it can be specified by official parameters.
> Like the NativeClient, the official parameters should be specified by 
> "connect-timeout" in gemfire.properties.
> Timeout values ​​are determined in the following order of priority.
> 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT
> 2. java system property:gemfire.connect-timeout
> 3. gemfire.properties:connect-timeout
> 4. default:59000 milli seconds
> As another idea, there is also an idea to make it possible to specify it as 
> an attribute of Pool. In that case NativeClient needs the same modification.



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


[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

2017-05-26 Thread masaki-yamakawa
Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
@galen-pivotal
Thank you very much. I confirmed the message sent to the dev mailing list.


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


[jira] [Commented] (GEODE-2952) gfsh doesn't support exact match lucene queries

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/545
  
+1 Looks good!

On Fri, May 26, 2017 at 3:15 PM, Karen Miller 
wrote:

> @DivineEnder  @upthewaterspout
>  @boglesby
>  @nabarunnag 
> @ladyVader  @dihardman
> 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/545
> Commit Summary
>
>- GEODE-2952 document quoting of exact match Lucene queries
>
> File Changes
>
>- *M* geode-docs/tools_modules/gfsh/command-pages/search.html.md.erb
> (15)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/545.patch
>- https://github.com/apache/geode/pull/545.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 

> .
>



> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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


[GitHub] geode issue #545: GEODE-2952 document quoting of exact match Lucene queries

2017-05-26 Thread dihardman
Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/545
  
+1 Looks good!

On Fri, May 26, 2017 at 3:15 PM, Karen Miller 
wrote:

> @DivineEnder  @upthewaterspout
>  @boglesby
>  @nabarunnag 
> @ladyVader  @dihardman
> 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/545
> Commit Summary
>
>- GEODE-2952 document quoting of exact match Lucene queries
>
> File Changes
>
>- *M* geode-docs/tools_modules/gfsh/command-pages/search.html.md.erb
> (15)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/545.patch
>- https://github.com/apache/geode/pull/545.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 

> .
>



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


[jira] [Resolved] (GEODE-2949) Creating a lucene index containing a slash and then the region using gfsh causes an inconsistent state

2017-05-26 Thread Diane Hardman (JIRA)

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

Diane Hardman resolved GEODE-2949.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

Resolved with fix for GEODE-2950.

> Creating a lucene index containing a slash and then the region using gfsh 
> causes an inconsistent state
> --
>
> Key: GEODE-2949
> URL: https://issues.apache.org/jira/browse/GEODE-2949
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: Diane Hardman
> Fix For: 1.2.0
>
>
> Creating an index containing a slash with gfsh is successful:
> {noformat}
> gfsh>create lucene index --name='/slashed with spaces' --region=sam 
> --field=text
>Member| Status
>  | -
> 192.168.2.4(server2:52699):1026 | Successfully created lucene index
> 192.168.2.4(server1:52692):1025 | Successfully created lucene index
> {noformat}
> And creating the region with gfsh fails:
> {noformat}
> gfsh>create region --name=sam --type=PARTITION
> Member  | Status
> --- | --
> server2 | ERROR: name cannot contain the separator ' / '
> server1 | ERROR: name cannot contain the separator ' / '
> {noformat}
> But the logs show the async event queue and region have been created:
> {noformat}
> [info 2017/05/18 11:25:53.089 PDT server2  
> tid=0x41] Started  ParallelGatewaySender{id=AsyncEventQueue_/slashed with 
> spaces#_sam,remoteDsId=-1,isRunning =true}
> [info 2017/05/18 11:25:53.094 PDT server2  
> tid=0x41] Partitioned Region /sam is born with prId=11 ident:#sam
> {noformat}
> And destroying the index says no indexes were found:
> {noformat}
>  gfsh>destroy lucene index --region=/data
>Member| Status
>  | 
> 
> 192.168.2.4(server1:52692):1025 | No Lucene indexes were found in region 
> /data
> 192.168.2.4(server2:52699):1026 | No Lucene indexes were found in region 
> /data
> {noformat}



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


[jira] [Assigned] (GEODE-2949) Creating a lucene index containing a slash and then the region using gfsh causes an inconsistent state

2017-05-26 Thread Diane Hardman (JIRA)

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

Diane Hardman reassigned GEODE-2949:


Assignee: Diane Hardman

> Creating a lucene index containing a slash and then the region using gfsh 
> causes an inconsistent state
> --
>
> Key: GEODE-2949
> URL: https://issues.apache.org/jira/browse/GEODE-2949
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: Diane Hardman
>
> Creating an index containing a slash with gfsh is successful:
> {noformat}
> gfsh>create lucene index --name='/slashed with spaces' --region=sam 
> --field=text
>Member| Status
>  | -
> 192.168.2.4(server2:52699):1026 | Successfully created lucene index
> 192.168.2.4(server1:52692):1025 | Successfully created lucene index
> {noformat}
> And creating the region with gfsh fails:
> {noformat}
> gfsh>create region --name=sam --type=PARTITION
> Member  | Status
> --- | --
> server2 | ERROR: name cannot contain the separator ' / '
> server1 | ERROR: name cannot contain the separator ' / '
> {noformat}
> But the logs show the async event queue and region have been created:
> {noformat}
> [info 2017/05/18 11:25:53.089 PDT server2  
> tid=0x41] Started  ParallelGatewaySender{id=AsyncEventQueue_/slashed with 
> spaces#_sam,remoteDsId=-1,isRunning =true}
> [info 2017/05/18 11:25:53.094 PDT server2  
> tid=0x41] Partitioned Region /sam is born with prId=11 ident:#sam
> {noformat}
> And destroying the index says no indexes were found:
> {noformat}
>  gfsh>destroy lucene index --region=/data
>Member| Status
>  | 
> 
> 192.168.2.4(server1:52692):1025 | No Lucene indexes were found in region 
> /data
> 192.168.2.4(server2:52699):1026 | No Lucene indexes were found in region 
> /data
> {noformat}



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


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

2017-05-26 Thread Spring CI

---
Spring Data GemFire > Nightly-ApacheGeode > #566 was successful.
---
Scheduled
1850 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

[jira] [Commented] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/542
  
+1


> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a 
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD 
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator  
> tid=0x7f] null
> java.lang.NullPointerException
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.



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


[GitHub] geode issue #542: GEODE-2951 Remove --pageSize from docs of gfsh search luce...

2017-05-26 Thread joeymcallister
Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/542
  
+1


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


[jira] [Updated] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD

2017-05-26 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller updated GEODE-3002:
---
Priority: Minor  (was: Major)

> Improve doc of (Lucene) __REGION_VALUE_FIELD
> 
>
> Key: GEODE-3002
> URL: https://issues.apache.org/jira/browse/GEODE-3002
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Priority: Minor
>
> The original description of {{__REGION_VALUE_FIELD}} is not quite right. In 
> addition, there is an example gfsh command using this value that is wrong.  
> It is in the {{gfsh create lucene index}} command reference page.



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


[jira] [Assigned] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD

2017-05-26 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller reassigned GEODE-3002:
--

Assignee: Karen Smoler Miller

> Improve doc of (Lucene) __REGION_VALUE_FIELD
> 
>
> Key: GEODE-3002
> URL: https://issues.apache.org/jira/browse/GEODE-3002
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>Priority: Minor
>
> The original description of {{__REGION_VALUE_FIELD}} is not quite right. In 
> addition, there is an example gfsh command using this value that is wrong.  
> It is in the {{gfsh create lucene index}} command reference page.



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


[jira] [Created] (GEODE-3002) Improve doc of (Lucene) __REGION_VALUE_FIELD

2017-05-26 Thread Karen Smoler Miller (JIRA)
Karen Smoler Miller created GEODE-3002:
--

 Summary: Improve doc of (Lucene) __REGION_VALUE_FIELD
 Key: GEODE-3002
 URL: https://issues.apache.org/jira/browse/GEODE-3002
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Karen Smoler Miller


The original description of {{__REGION_VALUE_FIELD}} is not quite right. In 
addition, there is an example gfsh command using this value that is wrong.  It 
is in the {{gfsh create lucene index}} command reference page.



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


[jira] [Commented] (GEODE-2952) gfsh doesn't support exact match lucene queries

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2952 document quoting of exact match Lucene queries

@DivineEnder @upthewaterspout @boglesby @nabarunnag @ladyVader @dihardman
Please review.


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

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

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

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


commit 71f01758e1fa7535fc19dffb542293b8eddbac31
Author: Karen Miller 
Date:   2017-05-26T22:10:43Z

GEODE-2952 document quoting of exact match Lucene queries




> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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


[GitHub] geode pull request #545: GEODE-2952 document quoting of exact match Lucene q...

2017-05-26 Thread karensmolermiller
GitHub user karensmolermiller opened a pull request:

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

GEODE-2952 document quoting of exact match Lucene queries

@DivineEnder @upthewaterspout @boglesby @nabarunnag @ladyVader @dihardman
Please review.


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

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

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

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


commit 71f01758e1fa7535fc19dffb542293b8eddbac31
Author: Karen Miller 
Date:   2017-05-26T22:10:43Z

GEODE-2952 document quoting of exact match Lucene queries




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


[jira] [Commented] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/542
  
+1 - Looks fine to me.


On Fri, May 26, 2017 at 12:30 PM, Dave Barnes 
wrote:

> *@davebarnes97* approved this pull request.
>
> LGTM +1
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or 
mute
> the thread
> 

> .
>



> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a 
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD 
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator  
> tid=0x7f] null
> java.lang.NullPointerException
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.



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


[GitHub] geode issue #542: GEODE-2951 Remove --pageSize from docs of gfsh search luce...

2017-05-26 Thread dihardman
Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/542
  
+1 - Looks fine to me.


On Fri, May 26, 2017 at 12:30 PM, Dave Barnes 
wrote:

> *@davebarnes97* approved this pull request.
>
> LGTM +1
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or 
mute
> the thread
> 

> .
>



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


Re: Review Request 59611: GEODE-2989: Improve mechanism for scanning the classpath to find gfsh commands

2017-05-26 Thread Jared Stewart

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

(Updated May 26, 2017, 10:02 p.m.)


Review request for geode, Emily Yeh, Jinmei Liao, and Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2989: Improve mechanism for scanning the classpath to find gfsh commands


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
 0576e46fce08f9c969726817e0012a2094f79fbe 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ClasspathScanLoadHelper.java
 20fffbd5c492cfb4642ce41c937da3d499d3434c 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/ClasspathScanLoadHelperJUnitTest.java
 a13ca351c49da2bc523e6d3ad9dd3e845b7b0429 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java
 159c47ffbd71c6d08b563d8d28d5d7cdc4fb096b 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
 65fd528641771e535f3d8d0d6601cef53f91af7a 
  
geode-core/src/test/java/org/apache/geode/security/PDXPostProcessorDUnitTest.java
 e9523862da9e045b05417dd8123574b01622c497 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 30ae59fd786b4753ae71849f81deeb0fe7f74c17 
  
geode-web/src/test/java/org/apache/geode/management/internal/web/controllers/ShellCommandsControllerJUnitTest.java
 10e26f6c5d006856e9e88b06a60f5e67cb68a2ce 


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


Testing (updated)
---

- Precheckin passed
 - Further cleanup of CommandManager is expected in a subsequent ticket


Thanks,

Jared Stewart



[jira] [Commented] (GEODE-2941) Pulse documentation is outdated

2017-05-26 Thread ASF subversion and git services (JIRA)

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

ASF subversion and git services commented on GEODE-2941:


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

GEODE-2941 Pulse doc update - add logging config


> Pulse documentation is outdated
> ---
>
> Key: GEODE-2941
> URL: https://issues.apache.org/jira/browse/GEODE-2941
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Jinmei Liao
>Assignee: Dave Barnes
> Fix For: 1.2.0
>
>
> the pulse documentation:
> http://geode.apache.org/docs/guide/11/tools_modules/pulse/quickstart.html#topic_523F6DE33FE54307BBE8F83BB7D9355D
> is no longer accurate anymore.
> 1. jmxUsername and jmxpassword no long applies
> 2. the logging configurations has changed too.



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


[jira] [Reopened] (GEODE-2952) gfsh doesn't support exact match lucene queries

2017-05-26 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller reopened GEODE-2952:


Reopening this ticket, as we should document the use of the double quote marks 
in exact match query strings.

> gfsh doesn't support exact match lucene queries
> ---
>
> Key: GEODE-2952
> URL: https://issues.apache.org/jira/browse/GEODE-2952
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Barry Oglesby
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> This command:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='Police Dept'
> {noformat}
> Runs this lucene query:
> {noformat}
> Resolution_Description:police Resolution_Description:dept
> {noformat}
> I also tried this command which ran the same lucene query as above:
> {noformat}
> gfsh>search lucene --name=index --region=data 
> --defaultField=Resolution_Description --queryStrings='\"Police Dept\"'
> {noformat}
> The java API supports exact match queries with "" around the queryString. 
> Doing this causes this lucene query to be run:
> {noformat}
> Resolution_Description:"police dept"
> {noformat}



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


Re: RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread John Blum
Jinmei-

I think I am mistaken about the use of Apache's HTTP Components.  I know at
one time I experimented with using Apache's HTTP Components as more robust
solution (than JDK's URLConnection/HttpURLConnection) that is supported by
*Spring's* RestTemplate for client HTTP access, but I see

[1]
now that I just used *Spring's* SimpleClientHttpRequestFactory, which as
the Javadoc

[2]
explains, just uses JDK's facilities (i.e. URLConnection, or
specifically/technically, HttpURLConnection).

Still, *Spring* abstracts

[3]
the HTTP client in use, which the RestTemplate supports

[4],
therefore it would be possible to plugin

[5]
Apache's HTTP Components implementation, assuming, of course, Apache HTTP
Components are on the classpath.

So configuration of things, like HTTPS, auth, or other client HTTP protocol
specifics, must be configured at the JDK level, which seems to be in place, for
instance

 [6].

Hope this helps.

-j


[1]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java#L183
[2]
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/SimpleClientHttpRequestFactory.html
[3]
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/ClientHttpRequestFactory.html
[4]
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/client/RestTemplate.html#RestTemplate-org.springframework.http.client.ClientHttpRequestFactory-
[5]
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/http/client/HttpComponentsClientHttpRequestFactory.html
[6]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java#L447


On Fri, May 26, 2017 at 12:55 PM, John Blum  wrote:

> Response below...
>
> On Fri, May 26, 2017 at 11:49 AM, Jinmei Liao  wrote:
>
>> John, thank you for the detailed response. So the difference between these
>> two are the way request url is obtained, the RestHttpOperationInvoker
>> obtained the url from the returned LinkIndex map, while this
>> SimpleHttpOperationInvoker construct the url itself and eventually gets
>> something like  "...//management/commands/cmd=xyz".
>>
>>  Is that basically it?
>>
>>
> Essentially, yes.  The SimpleHttpOperationInvoker only ever uses the
> single, fixed Controller endpoint (/management/commands/cmd=xyz) where as
> the RestHttpOperationInvoker attempts to the corresponding URL for the
> *Gfsh* command in the Index.
>
> The RestHttpOperationInvoker delegates to the SimpleHttpOperationInvoker
> when the *Gfsh* command is not represented in the Index, i.e. does not
> have a dedicated URL.
>
>
>
>
>> On Fri, May 26, 2017 at 11:33 AM, John Blum  wrote:
>>
>> > Hi Jinmei-
>> >
>> > *> Do we know why in our admin rest api, we have these two kind
>> > of OpeationInvokers*
>> >
>> > Yes.
>> >
>> > The Javadoc
>> > > > core/src/main/java/org/apache/geode/management/internal/web/shell/
>> > SimpleHttpOperationInvoker.java#L33-L34>
>> > [1]
>> > somewhat explains the reason for this, but...
>> >
>> > In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
>> > REST service endpoints.
>> >
>> > First, are "Well-Known
>> > > > core/src/main/java/org/apache/geode/management/internal/web/
>> controllers/
>> > ShellCommandsController.java#L143-L294>"
>> > [2] with actual *Spring Web MVC* Controller Endpoints corresponding to
>> each
>> > of the *Gfsh* commands (e.g. `create region
>> > > > core/src/main/java/org/apache/geode/management/internal/web/
>> controllers/
>> > RegionCommandsController.java#L156-L228>`
>> > [3]).
>> >
>> > Then, there is a "Catch-all
>> > > > core/src/main/java/org/apache/geode/management/internal/web/
>> controllers/
>> > ShellCommandsController.java#L68-L70>"
>> > endpoint [4], which is what the SimpleH

Re: RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread John Blum
Response below...

On Fri, May 26, 2017 at 11:49 AM, Jinmei Liao  wrote:

> John, thank you for the detailed response. So the difference between these
> two are the way request url is obtained, the RestHttpOperationInvoker
> obtained the url from the returned LinkIndex map, while this
> SimpleHttpOperationInvoker construct the url itself and eventually gets
> something like  "...//management/commands/cmd=xyz".
>
>  Is that basically it?
>
>
Essentially, yes.  The SimpleHttpOperationInvoker only ever uses the
single, fixed Controller endpoint (/management/commands/cmd=xyz) where as
the RestHttpOperationInvoker attempts to the corresponding URL for the
*Gfsh* command in the Index.

The RestHttpOperationInvoker delegates to the SimpleHttpOperationInvoker
when the *Gfsh* command is not represented in the Index, i.e. does not have
a dedicated URL.




> On Fri, May 26, 2017 at 11:33 AM, John Blum  wrote:
>
> > Hi Jinmei-
> >
> > *> Do we know why in our admin rest api, we have these two kind
> > of OpeationInvokers*
> >
> > Yes.
> >
> > The Javadoc
> >  > core/src/main/java/org/apache/geode/management/internal/web/shell/
> > SimpleHttpOperationInvoker.java#L33-L34>
> > [1]
> > somewhat explains the reason for this, but...
> >
> > In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
> > REST service endpoints.
> >
> > First, are "Well-Known
> >  > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > ShellCommandsController.java#L143-L294>"
> > [2] with actual *Spring Web MVC* Controller Endpoints corresponding to
> each
> > of the *Gfsh* commands (e.g. `create region
> >  > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > RegionCommandsController.java#L156-L228>`
> > [3]).
> >
> > Then, there is a "Catch-all
> >  > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > ShellCommandsController.java#L68-L70>"
> > endpoint [4], which is what the SimpleHttpOperationInvoker
> >  > core/src/main/java/org/apache/geode/management/internal/web/shell/
> > SimpleHttpOperationInvoker.java#L49>
> > "invokes" [5].  The idea behind this endpoint was, often times, someone
> > would add a new command but forget to update the Admin REST API to match,
> > with "explicit" support (e.g. both this [2] and this [3]) for the new
> > command.
> >
> > While this later approach works, it is not highly recommended and is
> > certainly not very "REST-like", much less "REST-ful".
> >
> > In fact, the former, "Well-Known" endpoints I setup separately and
> > individually in order to eventually introduce proper "Resource
> > abstractions" for each of the REST API service endpoints for each of the
> > *Gfsh* commands rather than the very use of HTTP Request Parameters to
> > naively "reconstruct" the Gfsh command-line syntax that is largely still
> in
> > place today.  However, I never got that far before the priorities
> changed.
> >
> > So, *Gfsh* selects which HTTP-based OperationInvoker to use based on the
> > availability of the command in the Admin REST API "Index" [2].
> >
> > Anyway, there is much to know in terms of the reasons why this API was
> > designed the way it was at the time.  I'd say it still needs a lot of
> work
> > realize the full vision I had for it when it was created, something I
> > documented quite well and gave to the leadership team at that time.
> >
> > If you have more questions, let's talk live.
> >
> > Cheers,
> > John
> >
> >
> > [1]
> > https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/web/shell/
> > SimpleHttpOperationInvoker.java#L33-L34
> > [2]
> > https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > ShellCommandsController.java#L143-L294
> > [3]
> > https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > RegionCommandsController.java#L156-L228
> > [4]
> > https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/web/controllers/
> > ShellCommandsController.java#L68-L70
> > [5]
> > https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> > core/src/main/java/org/apache/geode/management/internal/web/shell/
> > SimpleHttpOperationInvoker.java#L49
> >
> >
> > On Fri, May 26, 2017 at 9:59 AM, Jinmei Liao  wrote:
> >
> > > Hi, team,
> > >
> > > Do we know why in our admin rest api, we have these two kind of
> > > OpeationInvokers, it looks like when RestHttpOperationInvoker failed to
> > > find the resource, it will use the SimpleHttpOperationInvoker to try
> >

Re: RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread John Blum
I should also add that the RestHttpOperationInvoker even makes use

[1]
of the SimpleHttpOperationInvoker as a fallback.

There is also configuration for the underlying HTTP protocol "provider" as
well (which is where SSL and auth is configured at the HTTP level) that I
am trying to find in the Admin REST API  code but do not remember where I
put it.  I think it even used Apache HTTP Components to configure the HTTP
client or something like that. Gah.


[1]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/RestHttpOperationInvoker.java#L138

On Fri, May 26, 2017 at 11:33 AM, John Blum  wrote:

> Hi Jinmei-
>
> *> Do we know why in our admin rest api, we have these two kind
> of OpeationInvokers*
>
> Yes.
>
> The Javadoc
> 
>  [1]
> somewhat explains the reason for this, but...
>
> In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
> REST service endpoints.
>
> First, are "Well-Known
> "
> [2] with actual *Spring Web MVC* Controller Endpoints corresponding to
> each of the *Gfsh* commands (e.g. `create region
> `
> [3]).
>
> Then, there is a "Catch-all
> "
> endpoint [4], which is what the SimpleHttpOperationInvoker
> 
> "invokes" [5].  The idea behind this endpoint was, often times, someone
> would add a new command but forget to update the Admin REST API to match,
> with "explicit" support (e.g. both this [2] and this [3]) for the new
> command.
>
> While this later approach works, it is not highly recommended and is
> certainly not very "REST-like", much less "REST-ful".
>
> In fact, the former, "Well-Known" endpoints I setup separately and
> individually in order to eventually introduce proper "Resource
> abstractions" for each of the REST API service endpoints for each of the
> *Gfsh* commands rather than the very use of HTTP Request Parameters to
> naively "reconstruct" the Gfsh command-line syntax that is largely still in
> place today.  However, I never got that far before the priorities changed.
>
> So, *Gfsh* selects which HTTP-based OperationInvoker to use based on the
> availability of the command in the Admin REST API "Index" [2].
>
> Anyway, there is much to know in terms of the reasons why this API was
> designed the way it was at the time.  I'd say it still needs a lot of work
> realize the full vision I had for it when it was created, something I
> documented quite well and gave to the leadership team at that time.
>
> If you have more questions, let's talk live.
>
> Cheers,
> John
>
>
> [1] https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L33-L34
> [2] https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L143-L294
> [3] https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> RegionCommandsController.java#L156-L228
> [4] https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L68-L70
> [5] https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L49
>
>
> On Fri, May 26, 2017 at 9:59 AM, Jinmei Liao  wrote:
>
>> Hi, team,
>>
>> Do we know why in our admin rest api, we have these two kind of
>> OpeationInvokers, it looks like when RestHttpOperationInvoker failed to
>> find the resource, it will use the SimpleHttpOperationInvoker to try
>> again,
>> but shouldn't that also fail as well?
>>
>> Here is some of the logic I found in the code. I am wondering why this is
>> necessary.
>>
>> .
>> if( link is not available){
>> throw new RestApiCallForCommandNotFoundException(
>>
>>   String.format("No REST API call for command (%1$s) was found!",
>> command.get

[jira] [Assigned] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

2017-05-26 Thread Emily Yeh (JIRA)

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

Emily Yeh reassigned GEODE-2818:


Assignee: Emily Yeh

> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>Assignee: Emily Yeh
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



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


[jira] [Updated] (GEODE-2991) "destroy gateway-sender" command not in documentation

2017-05-26 Thread Emily Yeh (JIRA)

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

Emily Yeh updated GEODE-2991:
-
Priority: Minor  (was: Major)

> "destroy gateway-sender" command not in documentation
> -
>
> Key: GEODE-2991
> URL: https://issues.apache.org/jira/browse/GEODE-2991
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Emily Yeh
>Priority: Minor
>
> Documentation for the "destroy gateway-sender" command (handled by the 
> destroyGatewaySender method under WanCommands.java) isn't available in the 
> docs yet.



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


[jira] [Assigned] (GEODE-2977) commands should take string[] as the value for --group and --memberId(--name) whenever possible

2017-05-26 Thread Emily Yeh (JIRA)

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

Emily Yeh reassigned GEODE-2977:


Assignee: Emily Yeh

> commands should take string[] as the value for --group and --memberId(--name) 
> whenever possible
> ---
>
> Key: GEODE-2977
> URL: https://issues.apache.org/jira/browse/GEODE-2977
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Jinmei Liao
>Assignee: Emily Yeh
>
> some commands takes string[], and some takes only String and split them 
> manually. We should make this consistent and the help message would be a lot 
> clearer if taking string[].



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


[jira] [Commented] (GEODE-2994) Doc task: interactions of backups with persistence

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2994 Take backups when region ops are quiescent

@upthewaterspout @joeymcallister @davebarnes97 @dihardman @ladyVader 
@boglesby 
Please review.


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

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

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

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


commit 4affd0b7103b7b6630b38c63ba8c2e1b5f4bd1a0
Author: Karen Miller 
Date:   2017-05-26T17:29:29Z

GEODE-2994 Take backups when region ops are quiescent




> Doc task: interactions of backups with persistence
> --
>
> Key: GEODE-2994
> URL: https://issues.apache.org/jira/browse/GEODE-2994
> Project: Geode
>  Issue Type: Improvement
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Document that an inconsistent state can occur by using a backup to restore 
> system state, if the backup is made at the wrong time.
> There are 2 examples where persistence and taking a backup might cause an 
> inconsistency with region data, if that backup is used to restore a system.
> # *A Lucene index.* The Lucene index is persistent. If a backup is unlucky 
> enough to be taken between a persisted write to a region (disk op) and a 
> persisted write to the Lucene index (disk op), then the backup represents 
> inconsistent data in the region and Lucene index.
> # *An AEQ.* The AEQ is persistent. If a backup is unlucky enough to be taken 
> between a persisted write to a region (disk op) and a persisted write to the 
> AEQ (disk op), then the backup represents inconsistent data in the region and 
> the AEQ.
> The solution is to make sure that backups are taken when the system is 
> quiescent WRT region operations.



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


[GitHub] geode pull request #544: GEODE-2994 Take backups when region ops are quiesce...

2017-05-26 Thread karensmolermiller
GitHub user karensmolermiller opened a pull request:

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

GEODE-2994 Take backups when region ops are quiescent

@upthewaterspout @joeymcallister @davebarnes97 @dihardman @ladyVader 
@boglesby 
Please review.


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

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

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

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


commit 4affd0b7103b7b6630b38c63ba8c2e1b5f4bd1a0
Author: Karen Miller 
Date:   2017-05-26T17:29:29Z

GEODE-2994 Take backups when region ops are quiescent




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


[jira] [Created] (GEODE-3001) Need to document how to insert/remove objects from gfsh

2017-05-26 Thread Swapnil Bawaskar (JIRA)
Swapnil Bawaskar created GEODE-3001:
---

 Summary: Need to document how to insert/remove objects from gfsh
 Key: GEODE-3001
 URL: https://issues.apache.org/jira/browse/GEODE-3001
 Project: Geode
  Issue Type: Task
  Components: docs
Reporter: Swapnil Bawaskar


In addition to simple primitives, gfsh put/remove commands can specify domain 
object keys and values expressed as json.

Say you have the following domain object that you would like to use as key:
{noformat}
package io.pivotal.gemfire.testing;

import java.io.Serializable;
public class MyKey implements Serializable {
 private static final long serialVersionUID = 2552455191256578368L;
  private String identifier;
  private String name;
  public MyKey(){
  }

  public MyKey(String identifier, String name){
this.identifier=identifier;
this.name=name;
  }

  public String getIdentifier() {
return identifier;
  }

  public void setIdentifier(String identifier) {
this.identifier = identifier;
  }

  public String getName() {
return name;
  }

  public void setName(String name) {
this.name = name;
  }

  @Override public boolean equals(Object obj) {
if (obj instanceof MyKey) {
  MyKey other = (MyKey) obj;
  if (this.identifier.equals(other.getIdentifier())
  && this.name.equals(other.getName())) {
return true;
  }
}
return false;
  }

  @Override public int hashCode() {
return this.identifier.hashCode()/31 + this.name.hashCode()/31;
  }
}
{noformat}

You can use the object as json like so:
{noformat}
gfsh>put --key-class=io.pivotal.gemfire.testing.MyKey --key="{'identifier': 
'KIWI131117+65', 'name':'name'}" --value=foo2 --region=/foo
{noformat}



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


[jira] [Commented] (GEODE-2957) null used as a default parameter when specifying analyzers

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2957 gfsh create lucene index "null" becomes "DEFAULT"

@DivineEnder @nabarunnag @ladyVader @boglesby @joeymcallister @davebarnes97 
Please review.

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

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

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

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


commit fd7dfd0f61f8e46ff8b3a157ffa8f8dacdf74d31
Author: Karen Miller 
Date:   2017-05-26T18:57:49Z

GEODE-2957 gfsh create lucene index "null" becomes "DEFAULT"




> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



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


[GitHub] geode pull request #543: GEODE-2957 gfsh create lucene index "null" becomes ...

2017-05-26 Thread karensmolermiller
GitHub user karensmolermiller opened a pull request:

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

GEODE-2957 gfsh create lucene index "null" becomes "DEFAULT"

@DivineEnder @nabarunnag @ladyVader @boglesby @joeymcallister @davebarnes97 
Please review.

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

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

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

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


commit fd7dfd0f61f8e46ff8b3a157ffa8f8dacdf74d31
Author: Karen Miller 
Date:   2017-05-26T18:57:49Z

GEODE-2957 gfsh create lucene index "null" becomes "DEFAULT"




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


Re: RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread Jinmei Liao
John, thank you for the detailed response. So the difference between these
two are the way request url is obtained, the RestHttpOperationInvoker
obtained the url from the returned LinkIndex map, while this
SimpleHttpOperationInvoker construct the url itself and eventually gets
something like  "...//management/commands/cmd=xyz".

 Is that basically it?


On Fri, May 26, 2017 at 11:33 AM, John Blum  wrote:

> Hi Jinmei-
>
> *> Do we know why in our admin rest api, we have these two kind
> of OpeationInvokers*
>
> Yes.
>
> The Javadoc
>  core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L33-L34>
> [1]
> somewhat explains the reason for this, but...
>
> In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
> REST service endpoints.
>
> First, are "Well-Known
>  core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L143-L294>"
> [2] with actual *Spring Web MVC* Controller Endpoints corresponding to each
> of the *Gfsh* commands (e.g. `create region
>  core/src/main/java/org/apache/geode/management/internal/web/controllers/
> RegionCommandsController.java#L156-L228>`
> [3]).
>
> Then, there is a "Catch-all
>  core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L68-L70>"
> endpoint [4], which is what the SimpleHttpOperationInvoker
>  core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L49>
> "invokes" [5].  The idea behind this endpoint was, often times, someone
> would add a new command but forget to update the Admin REST API to match,
> with "explicit" support (e.g. both this [2] and this [3]) for the new
> command.
>
> While this later approach works, it is not highly recommended and is
> certainly not very "REST-like", much less "REST-ful".
>
> In fact, the former, "Well-Known" endpoints I setup separately and
> individually in order to eventually introduce proper "Resource
> abstractions" for each of the REST API service endpoints for each of the
> *Gfsh* commands rather than the very use of HTTP Request Parameters to
> naively "reconstruct" the Gfsh command-line syntax that is largely still in
> place today.  However, I never got that far before the priorities changed.
>
> So, *Gfsh* selects which HTTP-based OperationInvoker to use based on the
> availability of the command in the Admin REST API "Index" [2].
>
> Anyway, there is much to know in terms of the reasons why this API was
> designed the way it was at the time.  I'd say it still needs a lot of work
> realize the full vision I had for it when it was created, something I
> documented quite well and gave to the leadership team at that time.
>
> If you have more questions, let's talk live.
>
> Cheers,
> John
>
>
> [1]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L33-L34
> [2]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L143-L294
> [3]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> RegionCommandsController.java#L156-L228
> [4]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/controllers/
> ShellCommandsController.java#L68-L70
> [5]
> https://github.com/apache/geode/blob/rel/v1.1.1/geode-
> core/src/main/java/org/apache/geode/management/internal/web/shell/
> SimpleHttpOperationInvoker.java#L49
>
>
> On Fri, May 26, 2017 at 9:59 AM, Jinmei Liao  wrote:
>
> > Hi, team,
> >
> > Do we know why in our admin rest api, we have these two kind of
> > OpeationInvokers, it looks like when RestHttpOperationInvoker failed to
> > find the resource, it will use the SimpleHttpOperationInvoker to try
> again,
> > but shouldn't that also fail as well?
> >
> > Here is some of the logic I found in the code. I am wondering why this is
> > necessary.
> >
> > .
> > if( link is not available){
> > throw new RestApiCallForCommandNotFoundException(
> >
> >   String.format("No REST API call for command (%1$s) was found!",
> > command.getInput()));
> > }
> >
> > somewhere else in the process:
> >
> > catch (RestApiCallForCommandNotFoundException e) {
> >
> > SimpleHttpOperationInvoker.processCommand()
> >
> > }
> >
> >
> > --
> > Cheers
> >
> > Jinmei
> >
>
>
>
> --
> -John
> john.blum10101 (skype)
>



-- 
Cheers

Jinmei


Review Request 59611: GEODE-2989: Improve mechanism for scanning the classpath to find gfsh commands

2017-05-26 Thread Jared Stewart

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

Review request for geode.


Repository: geode


Description
---

GEODE-2989: Improve mechanism for scanning the classpath to find gfsh commands


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CommandManager.java
 0576e46fce08f9c969726817e0012a2094f79fbe 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/ClasspathScanLoadHelper.java
 20fffbd5c492cfb4642ce41c937da3d499d3434c 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/ClasspathScanLoadHelperJUnitTest.java
 a13ca351c49da2bc523e6d3ad9dd3e845b7b0429 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/shell/GfshInitFileJUnitTest.java
 159c47ffbd71c6d08b563d8d28d5d7cdc4fb096b 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/MemberMBeanSecurityJUnitTest.java
 65fd528641771e535f3d8d0d6601cef53f91af7a 
  
geode-core/src/test/java/org/apache/geode/security/PDXPostProcessorDUnitTest.java
 e9523862da9e045b05417dd8123574b01622c497 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/ServerStarterRule.java
 30ae59fd786b4753ae71849f81deeb0fe7f74c17 
  
geode-web/src/test/java/org/apache/geode/management/internal/web/controllers/ShellCommandsControllerJUnitTest.java
 10e26f6c5d006856e9e88b06a60f5e67cb68a2ce 


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


Testing
---

- Precheckin running
 - Further cleanup of CommandManager is expected in a subsequent ticket


Thanks,

Jared Stewart



Re: RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread John Blum
Hi Jinmei-

*> Do we know why in our admin rest api, we have these two kind
of OpeationInvokers*

Yes.

The Javadoc

[1]
somewhat explains the reason for this, but...

In a nutshell, the Management (or "Admin") REST-like API  has 2 type of
REST service endpoints.

First, are "Well-Known
"
[2] with actual *Spring Web MVC* Controller Endpoints corresponding to each
of the *Gfsh* commands (e.g. `create region
`
[3]).

Then, there is a "Catch-all
"
endpoint [4], which is what the SimpleHttpOperationInvoker

"invokes" [5].  The idea behind this endpoint was, often times, someone
would add a new command but forget to update the Admin REST API to match,
with "explicit" support (e.g. both this [2] and this [3]) for the new
command.

While this later approach works, it is not highly recommended and is
certainly not very "REST-like", much less "REST-ful".

In fact, the former, "Well-Known" endpoints I setup separately and
individually in order to eventually introduce proper "Resource
abstractions" for each of the REST API service endpoints for each of the
*Gfsh* commands rather than the very use of HTTP Request Parameters to
naively "reconstruct" the Gfsh command-line syntax that is largely still in
place today.  However, I never got that far before the priorities changed.

So, *Gfsh* selects which HTTP-based OperationInvoker to use based on the
availability of the command in the Admin REST API "Index" [2].

Anyway, there is much to know in terms of the reasons why this API was
designed the way it was at the time.  I'd say it still needs a lot of work
realize the full vision I had for it when it was created, something I
documented quite well and gave to the leadership team at that time.

If you have more questions, let's talk live.

Cheers,
John


[1]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/SimpleHttpOperationInvoker.java#L33-L34
[2]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L143-L294
[3]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/RegionCommandsController.java#L156-L228
[4]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ShellCommandsController.java#L68-L70
[5]
https://github.com/apache/geode/blob/rel/v1.1.1/geode-core/src/main/java/org/apache/geode/management/internal/web/shell/SimpleHttpOperationInvoker.java#L49


On Fri, May 26, 2017 at 9:59 AM, Jinmei Liao  wrote:

> Hi, team,
>
> Do we know why in our admin rest api, we have these two kind of
> OpeationInvokers, it looks like when RestHttpOperationInvoker failed to
> find the resource, it will use the SimpleHttpOperationInvoker to try again,
> but shouldn't that also fail as well?
>
> Here is some of the logic I found in the code. I am wondering why this is
> necessary.
>
> .
> if( link is not available){
> throw new RestApiCallForCommandNotFoundException(
>
>   String.format("No REST API call for command (%1$s) was found!",
> command.getInput()));
> }
>
> somewhere else in the process:
>
> catch (RestApiCallForCommandNotFoundException e) {
>
> SimpleHttpOperationInvoker.processCommand()
>
> }
>
>
> --
> Cheers
>
> Jinmei
>



-- 
-John
john.blum10101 (skype)


stdout logging

2017-05-26 Thread Jinmei Liao
Hi, In some of our dunit tests, if we started a server/locator with
'log-file' defined, the log would only go in that log file instead of also
in the stdout, then the console won't have much information. This is due to
our implementation of LogWriter, we actually go ahead and removed the
console log appender if the file is defined.
(LogService.removeConsoleAppender();)

I am wondering if this necessary, why do we need to remove the console
logger anyway? I tried gfsh without removing it, the log won't show up in
gfsh's output.

-- 
Cheers

Jinmei


[jira] [Created] (GEODE-3000) Refactor Admin rest request to send credentials in Authentication header and use spring security to authenticate it.

2017-05-26 Thread Jinmei Liao (JIRA)
Jinmei Liao created GEODE-3000:
--

 Summary: Refactor Admin rest request to send credentials in 
Authentication header and use spring security to authenticate it.
 Key: GEODE-3000
 URL: https://issues.apache.org/jira/browse/GEODE-3000
 Project: Geode
  Issue Type: Improvement
Reporter: Jinmei Liao


Currently, admin rest put security-password in the header and Jetty would log 
it in debug level, we should send the authentication information in the 
authentication header so that Jetty won't log them, and have the server side be 
able to authenticate that way.

Currently the way these rest requests are sent are different for different 
request. We need to uniform that first before we can do this refactoring.



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


[jira] [Commented] (GEODE-2951) A gfsh lucene query specifying --pageSize fails with a NullPointerException

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2951 Remove --pageSize from docs of gfsh search lucene

The code commit to remove this gfsh search lucene command line option has 
already been completed.  This PR updates the docs to remove the option from the 
command reference page.

@boglesby @davebarnes97 @joeymcallister @dihardman @upthewaterspout 
@nabarunnag @DivineEnder @ladyVader @jhuynh1 and any other interested parties
Can a couple of you do an ultra-quick review of this simple change to the 
docs, so that it can be merged in for inclusion in a Geode 1.2 release?

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

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

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

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


commit aaf6b546067477e41bcafb3153a1b49c4eb6
Author: Karen Miller 
Date:   2017-05-26T17:54:58Z

GEODE-2951 Remove --pageSize from docs of gfsh search lucene




> A gfsh lucene query specifying --pageSize fails with a NullPointerException
> ---
>
> Key: GEODE-2951
> URL: https://issues.apache.org/jira/browse/GEODE-2951
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> A gfsh lucene query specifying {{--pageSize}} fails with a 
> NullPointerException:
> {noformat}
> gfsh>search lucene --name=index --region=data --queryStrings=NYPD 
> --defaultField=Agency --pageSize=10
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: null
> {noformat}
> This exception is logged in the locator.log:
> {noformat}
> [info 2017/05/18 12:42:22.317 PDT locator  
> tid=0x7f] null
> java.lang.NullPointerException
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.displayResults(LuceneIndexCommands.java:476)
>   at 
> org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommands.searchIndex(LuceneIndexCommands.java:299)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {noformat}
> The same query without the {{--pageSize=10}} setting works fine.



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


[GitHub] geode pull request #542: GEODE-2951 Remove --pageSize from docs of gfsh sear...

2017-05-26 Thread karensmolermiller
GitHub user karensmolermiller opened a pull request:

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

GEODE-2951 Remove --pageSize from docs of gfsh search lucene

The code commit to remove this gfsh search lucene command line option has 
already been completed.  This PR updates the docs to remove the option from the 
command reference page.

@boglesby @davebarnes97 @joeymcallister @dihardman @upthewaterspout 
@nabarunnag @DivineEnder @ladyVader @jhuynh1 and any other interested parties
Can a couple of you do an ultra-quick review of this simple change to the 
docs, so that it can be merged in for inclusion in a Geode 1.2 release?

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

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

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

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


commit aaf6b546067477e41bcafb3153a1b49c4eb6
Author: Karen Miller 
Date:   2017-05-26T17:54:58Z

GEODE-2951 Remove --pageSize from docs of gfsh search lucene




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


[jira] [Commented] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user galen-pivotal closed the pull request at:

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


> Prototype Protobuf Protocol: Client can send Put Request
> 
>
> Key: GEODE-2582
> URL: https://issues.apache.org/jira/browse/GEODE-2582
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Addison
>Assignee: Galen O'Sullivan
>
> Using protobuf as the IDL for the [client-server 
> protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol],
> GIVEN I'm a community developer writing a new client
> AND I was given some protofiles
> AND I have established a connection to the Gemfire server
> WHEN the client sends over a put message and some data
> THEN I should be able to see my data in the cache as *JSON*
>  Out of scope:
> * Stats
> * PDX
> * Retry



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


[jira] [Commented] (GEODE-2582) Prototype Protobuf Protocol: Client can send Put Request

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/520
  
Closing, work is on the `feature/GEODE-2582` branch of `apache/geode`.


> Prototype Protobuf Protocol: Client can send Put Request
> 
>
> Key: GEODE-2582
> URL: https://issues.apache.org/jira/browse/GEODE-2582
> Project: Geode
>  Issue Type: Sub-task
>  Components: client/server
>Reporter: Addison
>Assignee: Galen O'Sullivan
>
> Using protobuf as the IDL for the [client-server 
> protocol|https://cwiki.apache.org/confluence/display/GEODE/New+Client+Server+Protocol],
> GIVEN I'm a community developer writing a new client
> AND I was given some protofiles
> AND I have established a connection to the Gemfire server
> WHEN the client sends over a put message and some data
> THEN I should be able to see my data in the cache as *JSON*
>  Out of scope:
> * Stats
> * PDX
> * Retry



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


[GitHub] geode pull request #520: GEODE-2582: New client can send a Put request with ...

2017-05-26 Thread galen-pivotal
Github user galen-pivotal closed the pull request at:

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


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


[GitHub] geode issue #520: GEODE-2582: New client can send a Put request with Protobu...

2017-05-26 Thread galen-pivotal
Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/520
  
Closing, work is on the `feature/GEODE-2582` branch of `apache/geode`.


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


[jira] [Commented] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/474
  
@masaki-yamakawa  Looks like Travis doesn't think the build has started. 
I've sent a message to the developer list; someone there should have an idea 
what the issue is.


> Add official Socket timeout parameter when connecting to servers/locators
> -
>
> Key: GEODE-2788
> URL: https://issues.apache.org/jira/browse/GEODE-2788
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Masaki Yamakawa
>Priority: Minor
>  Labels: patch
>
> When connecting from the client to the servers/locators, if the 
> servers/locators is not started, the connection can not be established and a 
> Socket timeout occurs.
> This timeout value is 59 seconds by default. This timeout value is too long. 
> This timeout value can be changed by specifying the unofficial parameter 
> "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I 
> corresponded so that it can be specified by official parameters.
> Like the NativeClient, the official parameters should be specified by 
> "connect-timeout" in gemfire.properties.
> Timeout values ​​are determined in the following order of priority.
> 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT
> 2. java system property:gemfire.connect-timeout
> 3. gemfire.properties:connect-timeout
> 4. default:59000 milli seconds
> As another idea, there is also an idea to make it possible to specify it as 
> an attribute of Pool. In that case NativeClient needs the same modification.



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


[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

2017-05-26 Thread galen-pivotal
Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/474
  
@masaki-yamakawa  Looks like Travis doesn't think the build has started. 
I've sent a message to the developer list; someone there should have an idea 
what the issue is.


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


Looks like Travis CI is hung?

2017-05-26 Thread Galen M O'Sullivan
It looks like Travis isn't even starting the build for this PR, which
should have started 5 or 6 hours ago:

Travis: https://travis-ci.org/apache/geode/builds/236348800
PR: https://github.com/apache/geode/pull/474

Does anyone know why it isn't building, or how to jiggle it and make it
restart?

Thanks,
Galen


[jira] [Commented] (GEODE-2818) add alias to any command's options that involves "group", "member", "jar"

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user YehEmily closed the pull request at:

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


> add alias to any command's options that involves "group", "member", "jar"
> -
>
> Key: GEODE-2818
> URL: https://issues.apache.org/jira/browse/GEODE-2818
> Project: Geode
>  Issue Type: New Feature
>  Components: docs, gfsh
>Reporter: Jinmei Liao
>
> Or anything that would have confusion about if we are going to use singular 
> or plural at all.
> 1) add alias for those options
> 2) make sure it parameter type is an array type, some method only accepts a 
> string and split it inside the command.



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


[GitHub] geode pull request #539: GEODE-2818: add alias to any command's options that...

2017-05-26 Thread YehEmily
Github user YehEmily closed the pull request at:

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


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


RestHttpOperationInvoker and SimpleHttpOperationInvoker

2017-05-26 Thread Jinmei Liao
Hi, team,

Do we know why in our admin rest api, we have these two kind of
OpeationInvokers, it looks like when RestHttpOperationInvoker failed to
find the resource, it will use the SimpleHttpOperationInvoker to try again,
but shouldn't that also fail as well?

Here is some of the logic I found in the code. I am wondering why this is
necessary.

.
if( link is not available){
throw new RestApiCallForCommandNotFoundException(

  String.format("No REST API call for command (%1$s) was found!",
command.getInput()));
}

somewhere else in the process:

catch (RestApiCallForCommandNotFoundException e) {

SimpleHttpOperationInvoker.processCommand()

}


-- 
Cheers

Jinmei


[jira] [Reopened] (GEODE-2957) null used as a default parameter when specifying analyzers

2017-05-26 Thread Karen Smoler Miller (JIRA)

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

Karen Smoler Miller reopened GEODE-2957:


Changing "null" to "DEFAULT" requires that the documentation of this feature 
also needs to change.  Reopening the ticket for this documentation task.

> null used as a default parameter when specifying analyzers
> --
>
> Key: GEODE-2957
> URL: https://issues.apache.org/jira/browse/GEODE-2957
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> null seems to be the way to specify using the default 
> StandardKeywordAnalyzer. This can be used when specifying a long list of 
> field/analyzers.  
> So the line may look like 
> --analyzers="null,SomeAnalyzer,null,null,SomeAnalyzer}
>  We should probably change that to default or some other keyword.  null seems 
> a bit confusing.



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


[jira] [Commented] (GEODE-2788) Add official Socket timeout parameter when connecting to servers/locators

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
I am sorry, once I rebase to confirm the build, travis-ci hangs for some 
reason.


> Add official Socket timeout parameter when connecting to servers/locators
> -
>
> Key: GEODE-2788
> URL: https://issues.apache.org/jira/browse/GEODE-2788
> Project: Geode
>  Issue Type: Improvement
>  Components: client/server, docs
>Reporter: Masaki Yamakawa
>Priority: Minor
>  Labels: patch
>
> When connecting from the client to the servers/locators, if the 
> servers/locators is not started, the connection can not be established and a 
> Socket timeout occurs.
> This timeout value is 59 seconds by default. This timeout value is too long. 
> This timeout value can be changed by specifying the unofficial parameter 
> "gemfire.PoolImpl.HANDSHAKE_TIMEOUT" in java system property, but I 
> corresponded so that it can be specified by official parameters.
> Like the NativeClient, the official parameters should be specified by 
> "connect-timeout" in gemfire.properties.
> Timeout values ​​are determined in the following order of priority.
> 1. java system property:gemfire.PoolImpl.HANDSHAKE_TIMEOUT
> 2. java system property:gemfire.connect-timeout
> 3. gemfire.properties:connect-timeout
> 4. default:59000 milli seconds
> As another idea, there is also an idea to make it possible to specify it as 
> an attribute of Pool. In that case NativeClient needs the same modification.



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


[GitHub] geode issue #474: GEODE-2788: Add official Socket timeout parameter when con...

2017-05-26 Thread masaki-yamakawa
Github user masaki-yamakawa commented on the issue:

https://github.com/apache/geode/pull/474
  
I am sorry, once I rebase to confirm the build, travis-ci hangs for some 
reason.


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


[jira] [Commented] (GEODE-2960) gfsh create index should trim from field names

2017-05-26 Thread ASF GitHub Bot (JIRA)

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

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

GitHub user deepakddixit opened a pull request:

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

GEODE-2960 : Trim field parameter values from create lucene index.

Added logic to trim leading and trailing spaces from values provided 
against 'field'.
Modify existing test case to verify changes.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [x] Have you written or updated unit tests to verify your changes?
   Updated existing test.
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
No new dependency added.

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/deepakddixit/incubator-geode bug/GEODE-2960

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

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


commit cd853456c2622412dbcb2cd0807be613070d1269
Author: Deepak Dixit 
Date:   2017-05-26T11:29:41Z

GEODE-2960 : Trim field parameter values from create lucene index.
Added logic to trim leading and trailing spaces from values provided 
against 'field'.
Modify existing test case to verify changes.




> gfsh create index should trim from field names
> --
>
> Key: GEODE-2960
> URL: https://issues.apache.org/jira/browse/GEODE-2960
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: Deepak Dixit
>
> When creating an index with specific fields, the parameter expects a comma 
> separated string.  However we are not trimming after splitting the string.  
> So if fields are defined as --field="name, age, height, weight" the indexed 
> fields are actually "name", " age", " height", " weight"
> The command should probably trim the spaces before creating the index.



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


[GitHub] geode pull request #541: GEODE-2960 : Trim field parameter values from creat...

2017-05-26 Thread deepakddixit
GitHub user deepakddixit opened a pull request:

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

GEODE-2960 : Trim field parameter values from create lucene index.

Added logic to trim leading and trailing spaces from values provided 
against 'field'.
Modify existing test case to verify changes.

Thank you for submitting a contribution to Apache Geode.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

- [x] Has your PR been rebased against the latest commit within the target 
branch (typically `develop`)?

- [x] Is your initial contribution a single, squashed commit?

- [x] Does `gradlew build` run cleanly?

- [x] Have you written or updated unit tests to verify your changes?
   Updated existing test.
- [x] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
No new dependency added.

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and
submit an update to your PR as soon as possible. If you need help, please 
send an
email to dev@geode.apache.org.


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

$ git pull https://github.com/deepakddixit/incubator-geode bug/GEODE-2960

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

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


commit cd853456c2622412dbcb2cd0807be613070d1269
Author: Deepak Dixit 
Date:   2017-05-26T11:29:41Z

GEODE-2960 : Trim field parameter values from create lucene index.
Added logic to trim leading and trailing spaces from values provided 
against 'field'.
Modify existing test case to verify changes.




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


[jira] [Commented] (GEODE-2232) Rename GemFireConfigException

2017-05-26 Thread Dor (JIRA)

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

Dor commented on GEODE-2232:


Maybe we can duplicate those exceptions and mark all the GemFirexxxException as 
deprecated. As a suggestion. 
Let's say x versions from now it will be said to be removed from Apache Geode. 

> Rename GemFireConfigException
> -
>
> Key: GEODE-2232
> URL: https://issues.apache.org/jira/browse/GEODE-2232
> Project: Geode
>  Issue Type: Improvement
>  Components: docs, general
>Reporter: Dor
>Assignee: Bruce Schuchardt
>
> All GemFire*Exception classes should be refactor renamed to have Geode as a 
> prefix instead.
> For example:
>GemFireConfigException - Should be GeodeConfigException.
>GemFireException Should be GeodeException.



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