Build failed in Jenkins: Geode-nightly #852

[Apache Jenkins Server]

See 


Changes:

[kmiller] GEODE-2951 Remove --pageSize from docs of gfsh search lucene

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

[nnag] GEODE-2957: Create Lucene index analyzer help updated to include keyword

[nnag] Revert "GEODE-2957: Create Lucene index analyzer help updated to include

[nnag] GEODE-2957: Create Lucene index analyzer help updated to include keyword

[dbarnes] GEODE-2941 Update Pulse documentation: logging info

[kmiller] GEODE-2952 document quoting of exact match Lucene queries

[khowe] GEODE-2974: Remove GemFire product name from message string

[dbarnes] GEODE-2420: Warn a user if they try to export too much data - document

[kmiller] GEODE-2957 gfsh create lucene index "null" becomes "DEFAULT"

--
[...truncated 161.67 KB...]
:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources
:geode-json:testClasses
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-parent/2.4.0/randomizedtesting-parent-2.4.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.jar
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJavaNote: 

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

:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build

[jira] [Commented] (GEODE-2580) New Client/Server Protocol to make the development of clients easier

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2580:


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

GEODE-2580: Added Kotlin jars to geode-dependencies.jar


> New Client/Server Protocol to make the development of clients easier
> 
>
> Key: GEODE-2580
> URL: https://issues.apache.org/jira/browse/GEODE-2580
> Project: Geode
>  Issue Type: Wish
>  Components: client/server
>Reporter: Addison
>
> Today, writing a client in a new language (e.g. Go, Ruby, etc) is difficult 
> be the client/server protocol is now well documented and optimized for 
> super-low latency over maintainability.  The goal of this this epic is to 
> write a new client/server protocol that is well documented that will be the 
> foundation for future Geode client.
> This epic is broken down in the sub-tasks below.
> Please vote on this wish if you think it is a worthwhile endeavor.
> Note: no design choices are being made just yet. The first sub-task in this 
> epic is to make a former proposal to the developer list to discuss 
> foundational design choices.



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

[jira] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on the issue:

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

On Wed, May 31, 2017 at 4:24 PM, Karen Miller 
wrote:

> @joeymcallister  @dihardman
>  @boglesby 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/554
> Commit Summary
>
>- GEODE-3014 Document server/region/Lucene index start-up sequence
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (12)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/554.patch
>- https://github.com/apache/geode/pull/554.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 

> .
>



> Document gfsh create lucene index and region failure sequence
> -
>
> Key: GEODE-3014
> URL: https://issues.apache.org/jira/browse/GEODE-3014
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
>
> When creating a lucene index and region using gfsh, there is a specific 
> command sequence that causes the region to not be created successfully.
> The sequence that fails is:
> - start server(s)
> - create lucene index
> - start additional server(s)
> - create region
> What fails about this sequence is the lucene index is not saved in cluster 
> configuration until after the region is created. Before the region is 
> created, its only saved locally in existing servers. Since new servers don't 
> have the index when the region is created, the index definitions aren't 
> consistent across servers. This causes the region to be created only in some 
> servers (either all the original ones with the index or all the new ones 
> without the index).
> An alternate sequence that succeeds is:
> - start server(s)
> - create lucene index
> - create region
> - start additional server(s)
> Once the region has been created, then both the lucene index and region are 
> saved in cluster configuration, so new servers will create both the region 
> and index.



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

[GitHub] geode issue #554: GEODE-3014 Document server/region/Lucene index start-up se...

[dihardman]

Github user dihardman commented on the issue:

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

On Wed, May 31, 2017 at 4:24 PM, Karen Miller 
wrote:

> @joeymcallister  @dihardman
>  @boglesby 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/554
> Commit Summary
>
>- GEODE-3014 Document server/region/Lucene index start-up sequence
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (12)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/554.patch
>- https://github.com/apache/geode/pull/554.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.
---

Re: Review Request 59564: GEODE-2892 implement sizeOnSever and isEmptyOnServer

[Darrel Schneider]

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




geode-core/src/main/java/org/apache/geode/cache/Region.java
Lines 2100 (patched)


Drop the "int". Do the same on the size javadocs


- Darrel Schneider


On May 31, 2017, 4:35 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59564/
> ---
> 
> (Updated May 31, 2017, 4:35 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2892
> https://issues.apache.org/jira/browse/GEODE-2892
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> implement sizeOnSever and isEmptyOnServer
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 0fa29c6 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
>  e35750b 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/AdminRegion.java
>  51f1fdb 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalDataSet.java 
> 8be8de1 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> f581856 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/RegionCreation.java
>  a107fb3 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> f19c4e7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/AbstractRegionJUnitTest.java
>  ce83165 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
>  9ca5ab9 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
>  d1eddbb 
>   geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
> 2b26cdc 
> 
> 
> Diff: https://reviews.apache.org/r/59564/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 59564: GEODE-2892 implement sizeOnSever and isEmptyOnServer

[Darrel Schneider]

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


Ship it!




Ship It!

- Darrel Schneider


On May 31, 2017, 4:35 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59564/
> ---
> 
> (Updated May 31, 2017, 4:35 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2892
> https://issues.apache.org/jira/browse/GEODE-2892
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> implement sizeOnSever and isEmptyOnServer
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/Region.java 0fa29c6 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
>  e35750b 
>   
> geode-core/src/main/java/org/apache/geode/internal/admin/remote/AdminRegion.java
>  51f1fdb 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalDataSet.java 
> 8be8de1 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> f581856 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/RegionCreation.java
>  a107fb3 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> f19c4e7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/AbstractRegionJUnitTest.java
>  ce83165 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
>  9ca5ab9 
>   
> geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
>  d1eddbb 
>   geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
> 2b26cdc 
> 
> 
> Diff: https://reviews.apache.org/r/59564/diff/3/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

1.2.0 release branch

[Anthony Baker]

I created a release branch for v1.2.0:  
release/1.2.0

The branch point is this commit:

commit d1ec508ee628f75d1f26dbfd6db5a237745623b5
Author: Kirk Lund 
Date:   Thu May 18 13:28:38 2017 -0700

GEODE-2632: refactoring preparations for SecurityService and BaseCommand 
changes


The version on /develop has been bumped to 1.3.0-SNAPSHOT.  Please set the ‘Fix 
Version’ in JIRA accordingly.

If you have changes that need to be part of the 1.2.0 release please 
cherry-pick them onto the release/1.2.0 branch.  Currently I only see these 
issue marked for 1.2.0:

GEODE-2661
GEODE-2892
GEODE-2908
GEODE-2979

Based on the dev list traffic it looks like there are more changes coming.  
GEODE-3003 may also be worth looking into.  If there is anything else please 
make sure there is a JIRA and let me know.


Please begin calling out release-worthy notes:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes


Thanks,
Anthony

[jira] [Commented] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-3003:
--

[~ukohlmeyer] Could this be a duplicate of GEODE-2534?

> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip, 
> geode-host1.zip, geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't 
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for 
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start 
> with the error 
> "org.apache.geode.GemFireConfigException: cluster configuration service not 
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally 
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1 
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh 
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to 
> the values of your host1 and host2
> 4) do the bullets 1)-4) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on both hosts. See that this 
> cluster start is successful.
> 3) kill locator and server processes on both hosts
> kill [locator-PID] [server-PID]
> 4) run ./start-locator.sh; ./start-server.sh on both hosts
> 5) see that actually there are two clusters: "host1-locator" and 
> "host1-server, host2-locator, host2-server" instead of one cluster. And 
> sometimes there is no "host1-server", because it shutdown with error "Region 
> /_ConfigurationRegion has potentially stale data. It is waiting for another 
> member to recover the latest data.".



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

[jira] [Assigned] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration

[Anthony Baker (JIRA)]

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

Anthony Baker reassigned GEODE-3003:


Assignee: Udo Kohlmeyer

> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
>  Issue Type: Bug
>  Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Udo Kohlmeyer
>Priority: Blocker
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip, 
> geode-host1.zip, geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't 
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for 
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start 
> with the error 
> "org.apache.geode.GemFireConfigException: cluster configuration service not 
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally 
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1 
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh 
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to 
> the values of your host1 and host2
> 4) do the bullets 1)-4) for host2, the folder where you unzip the file should 
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on both hosts. See that this 
> cluster start is successful.
> 3) kill locator and server processes on both hosts
> kill [locator-PID] [server-PID]
> 4) run ./start-locator.sh; ./start-server.sh on both hosts
> 5) see that actually there are two clusters: "host1-locator" and 
> "host1-server, host2-locator, host2-server" instead of one cluster. And 
> sometimes there is no "host1-server", because it shutdown with error "Region 
> /_ConfigurationRegion has potentially stale data. It is waiting for another 
> member to recover the latest data.".



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
Cache.xml XSD adding new 'partition by prefix' delimiter attribute
Implement XML parser
Generate cache.xml with new attributes

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
A partitioned region can be created using with 'partition by prefix' via 
cache.xml
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.


  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
PartitionByKey PartitionResolver
String key parser
Getters and setters added to PartitionAttributesFactory 
Getters and setters added to PartitionAttributes
Delimiter added to PartitionRegionAttributes

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
A String key without a delimiter is valid -- but will not be colocated
Providing a key with the correct delimiter routes the entry to the correct node
If partitionByPrefix has been set AND a PartitionResolver is set an 
IllegalArgumentException 
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.




> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Implement:
> Cache.xml XSD adding new 'partition by prefix' delimiter attribute
> Implement XML parser
> Generate cache.xml with new attributes
> Done:
> Code is reviewed and checked in
> Tests are created and pass
> Acceptance: 
> A partitioned region can be created using with 'partition by prefix' via 
> cache.xml
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
PartitionByKey PartitionResolver
String key parser
Getters and setters added to PartitionAttributesFactory 
Getters and setters added to PartitionAttributes
Delimiter added to PartitionRegionAttributes

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
A String key without a delimiter is valid -- but will not be colocated
Providing a key with the correct delimiter routes the entry to the correct node
If partitionByPrefix has been set AND a PartitionResolver is set an 
IllegalArgumentException 
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.



  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
PartitionByKey PartitionResolver
String key parser
Getters and setters PartitionAttributesFactory 


Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
A String key without a delimiter is valid -- but will not be colocated
Providing a key with the correct delimiter routes the entry to the correct node
If partitionByPrefix has been set AND a PartitionResolver is set an 
IllegalArgumentException 
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.




> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Implement:
> PartitionByKey PartitionResolver
> String key parser
> Getters and setters added to PartitionAttributesFactory 
> Getters and setters added to PartitionAttributes
> Delimiter added to PartitionRegionAttributes
> Done:
> Code is reviewed and checked in
> Tests are created and pass
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> A String key without a delimiter is valid -- but will not be colocated
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> If partitionByPrefix has been set AND a PartitionResolver is set an 
> IllegalArgumentException 
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Updated] (GEODE-2892) Add sizeOnServer and isEmptyOnServer to Region

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2892:
--
Fix Version/s: 1.2.0

> Add sizeOnServer and isEmptyOnServer to Region
> --
>
> Key: GEODE-2892
> URL: https://issues.apache.org/jira/browse/GEODE-2892
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>Assignee: Eric Shu
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> sizeOnServer 
> isEmptyOnServer 
> These could also be named something like size(boolean localSize) to keep the 
> API a less wordy.
> ACCEPTANCE:
> When a developer uses these methods then the result should be from the 
> server-side.   This includes accessor Regions.
> JavaDocs should be updated accordingly.



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

[jira] [Assigned] (GEODE-2892) Add sizeOnServer and isEmptyOnServer to Region

[Fred Krone (JIRA)]

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

Fred Krone reassigned GEODE-2892:
-

Assignee: Eric Shu

> Add sizeOnServer and isEmptyOnServer to Region
> --
>
> Key: GEODE-2892
> URL: https://issues.apache.org/jira/browse/GEODE-2892
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>Assignee: Eric Shu
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> To lower confusion while also not breaking backwards compatibility Region 
> needs explicit "onServer" methods.
> sizeOnServer 
> isEmptyOnServer 
> These could also be named something like size(boolean localSize) to keep the 
> API a less wordy.
> ACCEPTANCE:
> When a developer uses these methods then the result should be from the 
> server-side.   This includes accessor Regions.
> JavaDocs should be updated accordingly.



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

[jira] [Updated] (GEODE-2661) CacheListener gets invoked when an non-existent entry is removed using removeAll

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-2661:
--
Fix Version/s: 1.2.0

> CacheListener gets invoked when an non-existent entry is removed using 
> removeAll
> 
>
> Key: GEODE-2661
> URL: https://issues.apache.org/jira/browse/GEODE-2661
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Lynn Gallinat
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> When a non-existing entry is removed using removeAll from PartitionedRegion 
> (need to verify this on replicated), the CacheListener's aftrerDestroy 
> callback method gets invoked. The afterDestroy should not be invoked for 
> entry which is not present.
> How to reproduce.
> region.put (k1, v1)
> region.put (k2, v2)
> // Remove all from client
> List keys= Arrays.asList("k1", "k2", "k8");
> region.removeAll(l); 
> The afterDestroy call back will be invoked for k8. On server.



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
PartitionByKey PartitionResolver
String key parser
Getters and setters PartitionAttributesFactory 


Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
A String key without a delimiter is valid -- but will not be colocated
Providing a key with the correct delimiter routes the entry to the correct node
If partitionByPrefix has been set AND a PartitionResolver is set an 
IllegalArgumentException 
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.



  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
Cache.xml XSD adding new 'partition by prefix' attribute
Implement XML parser

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
A partitioned region can be created using with 'partition by prefix' via 
cache.xml
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.



> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Implement:
> PartitionByKey PartitionResolver
> String key parser
> Getters and setters PartitionAttributesFactory 
> Done:
> Code is reviewed and checked in
> Tests are created and pass
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> A String key without a delimiter is valid -- but will not be colocated
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> If partitionByPrefix has been set AND a PartitionResolver is set an 
> IllegalArgumentException 
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Commented] (GEODE-3013) Reduce logging level for FunctionExceptions : InternalFunctionInvocationTargetException: Multiple target nodes found for single hop operation

[ASF GitHub Bot (JIRA)]

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

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

Github user ladyVader closed the pull request at:

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


> Reduce logging level for FunctionExceptions : 
> InternalFunctionInvocationTargetException: Multiple target nodes found for 
> single hop operation
> -
>
> Key: GEODE-3013
> URL: https://issues.apache.org/jira/browse/GEODE-3013
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The following exception should not be logged as a warning with a full stack 
> dump (as it is not actionable by the user).
> Changing this to debug log level.
> {noformat}
> Multiple target nodes found for single hop operation
> [warning 2017/04/04 14:53:06.031 PDT bridgegemfire1_monaco_15778 
>  tid=0x98] Exception on server while 
> executing function : 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
>  Multiple target nodes found for single hop operation
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnBucketSet(PartitionedRegion.java:3684)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3344)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:225)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:563)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionSingleHop.cmdExecute(ExecuteRegionFunctionSingleHop.java:264)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
> {noformat}



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

[jira] [Commented] (GEODE-3013) Reduce logging level for FunctionExceptions : InternalFunctionInvocationTargetException: Multiple target nodes found for single hop operation

[ASF GitHub Bot (JIRA)]

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

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

Github user ladyVader commented on the issue:

https://github.com/apache/geode/pull/552
  
Actually, with this change, I'm still seeing these log messages in testing, 
so retracting this pull request.


> Reduce logging level for FunctionExceptions : 
> InternalFunctionInvocationTargetException: Multiple target nodes found for 
> single hop operation
> -
>
> Key: GEODE-3013
> URL: https://issues.apache.org/jira/browse/GEODE-3013
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The following exception should not be logged as a warning with a full stack 
> dump (as it is not actionable by the user).
> Changing this to debug log level.
> {noformat}
> Multiple target nodes found for single hop operation
> [warning 2017/04/04 14:53:06.031 PDT bridgegemfire1_monaco_15778 
>  tid=0x98] Exception on server while 
> executing function : 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
>  Multiple target nodes found for single hop operation
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnBucketSet(PartitionedRegion.java:3684)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3344)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:225)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:563)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionSingleHop.cmdExecute(ExecuteRegionFunctionSingleHop.java:264)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:519)
> {noformat}



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

[GitHub] geode issue #552: GEODE-3013: Reduce log level for FunctionInvocationTargetE...

[ladyVader]

Github user ladyVader commented on the issue:

https://github.com/apache/geode/pull/552
  
Actually, with this change, I'm still seeing these log messages in testing, 
so retracting this pull request.


---
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 pull request #552: GEODE-3013: Reduce log level for FunctionInvocation...

[ladyVader]

Github user ladyVader closed the pull request at:

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


---
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-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2947:


Commit 9d4465af8b1e0834f748cd64f29da12f30b34851 in geode's branch 
refs/heads/release/1.2.0 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=9d4465a ]

GEODE-2947: Error message is now specific to lucene indexes

(cherry picked from commit 5f4a7a905013dfa8f76f7419ea71aacae3614077)


> Improve error message (seen in gfsh) when attempting to destroy a region 
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via 
> gfsh), the error message returned is not clear.  It should state that the 
> lucene index should be destroyed prior to destroying the region.  
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent 
> region [/testRegion] in colocation chain cannot be destroyed, unless all its 
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}



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

Re: Review Request 59643: GEODE-3006: reduce the frequency of ping request and reduce the loglevel of login/logout messages

[Emily Yeh]

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


Ship it!




Ship It!

- Emily Yeh


On May 31, 2017, 10:46 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59643/
> ---
> 
> (Updated May 31, 2017, 10:46 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> disregard the diff for log4j2.xml changes, these are from the changeset of 
> another review request.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java
>  b342c6688e527b0ed67e0210c6f8befa15978818 
> 
> 
> Diff: https://reviews.apache.org/r/59643/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

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

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

Github user joeymcallister commented on the issue:

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


> Document gfsh create lucene index and region failure sequence
> -
>
> Key: GEODE-3014
> URL: https://issues.apache.org/jira/browse/GEODE-3014
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
>
> When creating a lucene index and region using gfsh, there is a specific 
> command sequence that causes the region to not be created successfully.
> The sequence that fails is:
> - start server(s)
> - create lucene index
> - start additional server(s)
> - create region
> What fails about this sequence is the lucene index is not saved in cluster 
> configuration until after the region is created. Before the region is 
> created, its only saved locally in existing servers. Since new servers don't 
> have the index when the region is created, the index definitions aren't 
> consistent across servers. This causes the region to be created only in some 
> servers (either all the original ones with the index or all the new ones 
> without the index).
> An alternate sequence that succeeds is:
> - start server(s)
> - create lucene index
> - create region
> - start additional server(s)
> Once the region has been created, then both the lucene index and region are 
> saved in cluster configuration, so new servers will create both the region 
> and index.



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

[GitHub] geode issue #554: GEODE-3014 Document server/region/Lucene index start-up se...

[joeymcallister]

Github user joeymcallister commented on the issue:

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

Re: Review Request 59564: GEODE-2892 implement sizeOnSever and isEmptyOnServer

[Eric Shu]

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

(Updated May 31, 2017, 11:35 p.m.)


Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
Gallinat.


Changes
---

Fix failure message in the test.


Bugs: GEODE-2892
https://issues.apache.org/jira/browse/GEODE-2892


Repository: geode


Description
---

implement sizeOnSever and isEmptyOnServer


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/cache/Region.java 0fa29c6 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 e35750b 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/AdminRegion.java
 51f1fdb 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalDataSet.java 
8be8de1 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
f581856 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/RegionCreation.java
 a107fb3 
  geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
f19c4e7 
  
geode-core/src/test/java/org/apache/geode/internal/cache/AbstractRegionJUnitTest.java
 ce83165 
  
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 9ca5ab9 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
 d1eddbb 
  geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
2b26cdc 


Diff: https://reviews.apache.org/r/59564/diff/3/

Changes: https://reviews.apache.org/r/59564/diff/2-3/


Testing
---

precheckin


Thanks,

Eric Shu

Re: [jira] [Updated] (GEODE-3005) A developer can create a Region with Partition Resolution using Java API

[Swapnil Bawaskar]

For this reason:
But since the user has to always add this delimiter to their string keys
perhaps it is better for them to have to explicitly configure what it is.

I would vote for a single configuration.



On Wed, May 31, 2017 at 4:17 PM Darrel Schneider 
wrote:

> The partition-by-prefix feature can be configured with gfsh, cache.xml, or
> apis.
>
> We did not want it to be configured as a PartitionResolver because that
> ends up with overly verbose configuration.
> You end up with something like: gfsh create region "foo"
> --partition-resolver=org.apache.geode.resolvers.PartitionByPrefix.class
> instead of: gfsh create region "foo" --partition-by-prefix=true
>
> The reason for two configuration attributes (a boolean to enable the
> feature, and a string to customize the default delimiter) was for clarity.
> We thought that most use cases would just use the boolean and set it to
> true because they could use the default delimiter.
> The configuration of the delimiter is only needed when your existing prefix
> string contains the default delimiter.
> If we have just one configuration attribute (the delimiter) then it needs
> to default to the empty string which means the feature is disabled.
> I originally was pushing for the single configuration attribute but was
> convinced by others that the two config attribute was better. I like the
> idea of geode having a predefined delimiter like ":" instead of it always
> needed to be configured if you are going to use it. But since the customer
> has to always add this delimiter to their string keys perhaps it is better
> for them to have to explicitly configure what it is.
>
> I do not like the idea of returning the entire key if no delimiter is
> found. This seems error prone. If a developer forgets to put the correct
> delimiter in a key I think it is better for it to fail fast then to just
> instead use the default hash of the entire key.
> In the example of a Customer and Customer.Orders region you would just use
> the normal "partition-by-key" policy on the Customer region and then
> configure "partition-by-prefix" on the Customer.Orders region. You have no
> need for both regions to be configured with "partition-by-prefix".
>
> If someone does want to have a mix of keys, some with prefixes and some
> without, on the same region then they could just implement their own
> PartitionResolver and have it support this mix. I don't see that
> "partition-by-prefix" needs to support this use case unless it is very
> common.
>
> On Wed, May 31, 2017 at 10:15 AM, Michael Stolz  wrote:
>
> > I don't really see a need for new Region api for this except to be able
> to
> > specify the delimeter.
> >
> > A developer can just specify the provided PartionByPrefix class for his
> > PartitionResolver during region creation?
> >
> > Providing a String key with no delimiter should just return the entire
> key,
> > NOT throw an error. That way the same PartitionResolver can be used for
> > both the Customer region and the Customer.Orders region and it just
> works.
> >
> > One more thing, we need to be able to specify a partition resolver via
> > gfsh.
> >
> > --
> > Mike Stolz
> > Principal Engineer - Gemfire Product Manager
> > Mobile: 631-835-4771 <(631)%20835-4771> <(631)%20835-4771>
> >
> > On May 30, 2017 3:26 PM, "Fred Krone (JIRA)"  wrote:
> >
> > >
> > >  [ https://issues.apache.org/jira/browse/GEODE-3005?page=com.at
> > > lassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> > >
> > > Fred Krone updated GEODE-3005:
> > > --
> > > Description:
> > > A user should be able to set partition by prefix programmatically when
> > > creating a partitioned region.
> > >
> > > This can only be done when creating a Region type PARTITION
> > >
> > > Acceptance:
> > > Partitioned region can be created using new 'partition by prefix'
> > > attributes (on/off, delimiter)
> > > Only String keys work -- all other keys throw an error
> > > Providing a key with the correct delimiter routes the entry to the
> > correct
> > > node
> > > Providing a key with no delimiter throws an error
> > >
> > >
> > >   was:
> > > A user should be able to set partition by prefix programmatically when
> > > creating a partitioned region.
> > >
> > > This can only be done when creating a Region type PARTITION
> > >
> > >
> > > > A developer can create a Region with Partition Resolution using Java
> > API
> > > > 
> > 
> > > >
> > > > Key: GEODE-3005
> > > > URL:
> https://issues.apache.org/jira/browse/GEODE-3005
> > > > Project: Geode
> > > >  Issue Type: Wish
> > > >  Components: regions
> > > >Reporter: Fred Krone
> > > >Assignee: Fred Krone
> > > >
> > > > A user should be able to set partition by prefix programmatically
> when
> > > creating a 

[jira] [Resolved] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes

[Barry Oglesby (JIRA)]

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

Barry Oglesby resolved GEODE-2947.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> Improve error message (seen in gfsh) when attempting to destroy a region 
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> If a user attempta to destroy region before destroying the lucene index (via 
> gfsh), the error message returned is not clear.  It should state that the 
> lucene index should be destroyed prior to destroying the region.  
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent 
> region [/testRegion] in colocation chain cannot be destroyed, unless all its 
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}



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

[jira] [Commented] (GEODE-2947) Improve error message (seen in gfsh) when attempting to destroy a region before destroying lucene indexes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2947:


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

GEODE-2947: Error message is now specific to lucene indexes


> Improve error message (seen in gfsh) when attempting to destroy a region 
> before destroying lucene indexes
> -
>
> Key: GEODE-2947
> URL: https://issues.apache.org/jira/browse/GEODE-2947
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> If a user attempta to destroy region before destroying the lucene index (via 
> gfsh), the error message returned is not clear.  It should state that the 
> lucene index should be destroyed prior to destroying the region.  
> Instead it states this:
> {noformat}
> Error occurred while destroying region "testRegion". Reason: The parent 
> region [/testRegion] in colocation chain cannot be destroyed, unless all its 
> children [[/testIndex#_testRegion.files]] are destroyed
> {noformat}



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

[jira] [Commented] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-3014 Document server/region/Lucene index start-up sequence

@joeymcallister @dihardman @boglesby Please review.

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

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

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

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


commit 8d1a1e68ac8b062a2cb78aa6ce232e0c0e43adce
Author: Karen Miller 
Date:   2017-05-31T23:21:27Z

GEODE-3014 Document server/region/Lucene index start-up sequence




> Document gfsh create lucene index and region failure sequence
> -
>
> Key: GEODE-3014
> URL: https://issues.apache.org/jira/browse/GEODE-3014
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
>
> When creating a lucene index and region using gfsh, there is a specific 
> command sequence that causes the region to not be created successfully.
> The sequence that fails is:
> - start server(s)
> - create lucene index
> - start additional server(s)
> - create region
> What fails about this sequence is the lucene index is not saved in cluster 
> configuration until after the region is created. Before the region is 
> created, its only saved locally in existing servers. Since new servers don't 
> have the index when the region is created, the index definitions aren't 
> consistent across servers. This causes the region to be created only in some 
> servers (either all the original ones with the index or all the new ones 
> without the index).
> An alternate sequence that succeeds is:
> - start server(s)
> - create lucene index
> - create region
> - start additional server(s)
> Once the region has been created, then both the lucene index and region are 
> saved in cluster configuration, so new servers will create both the region 
> and index.



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

[GitHub] geode pull request #554: GEODE-3014 Document server/region/Lucene index star...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-3014 Document server/region/Lucene index start-up sequence

@joeymcallister @dihardman @boglesby Please review.

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

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

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

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


commit 8d1a1e68ac8b062a2cb78aa6ce232e0c0e43adce
Author: Karen Miller 
Date:   2017-05-31T23:21:27Z

GEODE-3014 Document server/region/Lucene index start-up sequence




---
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 59564: GEODE-2892 implement sizeOnSever and isEmptyOnServer

[Eric Shu]

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

(Updated May 31, 2017, 11:21 p.m.)


Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
Gallinat.


Changes
---

Fix review comments. Added more test cases.


Bugs: GEODE-2892
https://issues.apache.org/jira/browse/GEODE-2892


Repository: geode


Description
---

implement sizeOnSever and isEmptyOnServer


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/cache/Region.java 0fa29c6 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ProxyRegion.java
 e35750b 
  
geode-core/src/main/java/org/apache/geode/internal/admin/remote/AdminRegion.java
 51f1fdb 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalDataSet.java 
8be8de1 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
f581856 
  
geode-core/src/main/java/org/apache/geode/internal/cache/xmlcache/RegionCreation.java
 a107fb3 
  geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
f19c4e7 
  
geode-core/src/test/java/org/apache/geode/internal/cache/AbstractRegionJUnitTest.java
 ce83165 
  
geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/ClientServerMiscDUnitTest.java
 9ca5ab9 
  
geode-core/src/test/java/org/apache/geode/security/ClientAuthenticationTestCase.java
 d1eddbb 
  geode-core/src/test/java/org/apache/geode/security/SecurityTestUtils.java 
2b26cdc 


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

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


Testing (updated)
---

precheckin


Thanks,

Eric Shu

Re: [jira] [Updated] (GEODE-3005) A developer can create a Region with Partition Resolution using Java API

[Darrel Schneider]

The partition-by-prefix feature can be configured with gfsh, cache.xml, or
apis.

We did not want it to be configured as a PartitionResolver because that
ends up with overly verbose configuration.
You end up with something like: gfsh create region "foo"
--partition-resolver=org.apache.geode.resolvers.PartitionByPrefix.class
instead of: gfsh create region "foo" --partition-by-prefix=true

The reason for two configuration attributes (a boolean to enable the
feature, and a string to customize the default delimiter) was for clarity.
We thought that most use cases would just use the boolean and set it to
true because they could use the default delimiter.
The configuration of the delimiter is only needed when your existing prefix
string contains the default delimiter.
If we have just one configuration attribute (the delimiter) then it needs
to default to the empty string which means the feature is disabled.
I originally was pushing for the single configuration attribute but was
convinced by others that the two config attribute was better. I like the
idea of geode having a predefined delimiter like ":" instead of it always
needed to be configured if you are going to use it. But since the customer
has to always add this delimiter to their string keys perhaps it is better
for them to have to explicitly configure what it is.

I do not like the idea of returning the entire key if no delimiter is
found. This seems error prone. If a developer forgets to put the correct
delimiter in a key I think it is better for it to fail fast then to just
instead use the default hash of the entire key.
In the example of a Customer and Customer.Orders region you would just use
the normal "partition-by-key" policy on the Customer region and then
configure "partition-by-prefix" on the Customer.Orders region. You have no
need for both regions to be configured with "partition-by-prefix".

If someone does want to have a mix of keys, some with prefixes and some
without, on the same region then they could just implement their own
PartitionResolver and have it support this mix. I don't see that
"partition-by-prefix" needs to support this use case unless it is very
common.

On Wed, May 31, 2017 at 10:15 AM, Michael Stolz  wrote:

> I don't really see a need for new Region api for this except to be able to
> specify the delimeter.
>
> A developer can just specify the provided PartionByPrefix class for his
> PartitionResolver during region creation?
>
> Providing a String key with no delimiter should just return the entire key,
> NOT throw an error. That way the same PartitionResolver can be used for
> both the Customer region and the Customer.Orders region and it just works.
>
> One more thing, we need to be able to specify a partition resolver via
> gfsh.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771 <(631)%20835-4771>
>
> On May 30, 2017 3:26 PM, "Fred Krone (JIRA)"  wrote:
>
> >
> >  [ https://issues.apache.org/jira/browse/GEODE-3005?page=com.at
> > lassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> >
> > Fred Krone updated GEODE-3005:
> > --
> > Description:
> > A user should be able to set partition by prefix programmatically when
> > creating a partitioned region.
> >
> > This can only be done when creating a Region type PARTITION
> >
> > Acceptance:
> > Partitioned region can be created using new 'partition by prefix'
> > attributes (on/off, delimiter)
> > Only String keys work -- all other keys throw an error
> > Providing a key with the correct delimiter routes the entry to the
> correct
> > node
> > Providing a key with no delimiter throws an error
> >
> >
> >   was:
> > A user should be able to set partition by prefix programmatically when
> > creating a partitioned region.
> >
> > This can only be done when creating a Region type PARTITION
> >
> >
> > > A developer can create a Region with Partition Resolution using Java
> API
> > > 
> 
> > >
> > > Key: GEODE-3005
> > > URL: https://issues.apache.org/jira/browse/GEODE-3005
> > > Project: Geode
> > >  Issue Type: Wish
> > >  Components: regions
> > >Reporter: Fred Krone
> > >Assignee: Fred Krone
> > >
> > > A user should be able to set partition by prefix programmatically when
> > creating a partitioned region.
> > > This can only be done when creating a Region type PARTITION
> > > Acceptance:
> > > Partitioned region can be created using new 'partition by prefix'
> > attributes (on/off, delimiter)
> > > Only String keys work -- all other keys throw an error
> > > Providing a key with the correct delimiter routes the entry to the
> > correct node
> > > Providing a key with no delimiter throws an error
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> >
>

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3000:


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

GEODE-3000: do not have jetty log at debug level


> 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-3011) gfsh example to do a Lucene query is incorrect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3011:


Commit f7e1ba2dcbe129af32d7f6226555ee09ec66d939 in geode's branch 
refs/heads/feature/GEODE-2632-19 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=f7e1ba2 ]

GEODE-3011 Correct a Lucene gfsh query example

This closes #553


> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2994:


Commit c1288ac87f1cdee0e34441ab181eeb0506ad4554 in geode's branch 
refs/heads/feature/GEODE-2632-19 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=c1288ac ]

GEODE-2994 Take backups when region ops are quiescent

This closes #544


> 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
> Fix For: 1.2.0
>
>
> 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)

[jira] [Commented] (GEODE-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactoring preparations for SecurityService and BaseCommand changes


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3002:


Commit 64e4f72774e1ee811ea7f920fcb9a9598191bd4a in geode's branch 
refs/heads/feature/GEODE-2632-19 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=64e4f72 ]

GEODE-3002 Clarify __REGION_VALUE_FIELD in Lucene docs

This closes #550


> 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
> Fix For: 1.2.0
>
>
> 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-2975) Attributes are not validated in lucene xml configuration

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2975:


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

GEODE-2975: Change the location of the lucene xsd

The lucene xsd was not in the right location on disk, which resulted in
a failure to validate lucene elements in the xml file.

Adding tests and validation for cases where lucene elements show up in the
wrong place, which we were unable to catch with the xsd validation.

This closes #538


> Attributes are not validated in lucene xml configuration
> 
>
> Key: GEODE-2975
> URL: https://issues.apache.org/jira/browse/GEODE-2975
> Project: Geode
>  Issue Type: Bug
>  Components: docs, lucene
>Reporter: Barry Oglesby
>Assignee: Dan Smith
> Fix For: 1.2.0
>
>
> No exception is thrown for a lucene xml configuration missing a required 
> attribute.
> No exception is thrown for a lucene xml configuration including an unknown 
> attribute.
> If a {{lucene:field}} element is defined like below, no exception is thrown 
> for the invalid attribute called {{namexx}} and no exceptio is thrown because 
> the required attribute called {{name}} is not included.
> {noformat}
> 
> {noformat}



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

[jira] [Commented] (GEODE-2967) Internal Errors thrown while executing queries involving self join

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2967:


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

GEODE-2967: Fixing a test change

* A query was modified in a test that was not intended to be changed.


> Internal Errors thrown while executing queries involving self join
> --
>
> Key: GEODE-2967
> URL: https://issues.apache.org/jira/browse/GEODE-2967
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: nabarun
>
> Issue:
> While executing queries like
> SELECT * FROM /pos p1 WHERE p1.id = p1.id
> leads to an internal error if Indexes are used.
> Solution:
> ResultCollection needs to be created instead of StructCollection in this 
> particular situation.



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2957:


Commit 806751805cb47877b609ee35cbfa21b362a3d7b3 in geode's branch 
refs/heads/feature/GEODE-2632-19 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=8067518 ]

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

This closes #543


> 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-2632) Integrated Security performance improvements

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2632:


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

GEODE-2632: refactoring preparations for SecurityService and BaseCommand changes


> Integrated Security performance improvements
> 
>
> Key: GEODE-2632
> URL: https://issues.apache.org/jira/browse/GEODE-2632
> Project: Geode
>  Issue Type: Improvement
>  Components: security
>Reporter: Jinmei Liao
>Assignee: Kirk Lund
>  Labels: performance
>
> There is a security check in Put65.cmdExecute() that, if removed, improved 
> the performance.
> The expense of this security call needs to be reduced in order to get the 
> performance back.



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Implement:
Cache.xml XSD adding new 'partition by prefix' attribute
Implement XML parser

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
A partitioned region can be created using with 'partition by prefix' via 
cache.xml
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.


  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.



> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Implement:
> Cache.xml XSD adding new 'partition by prefix' attribute
> Implement XML parser
> Done:
> Code is reviewed and checked in
> Tests are created and pass
> Acceptance: 
> A partitioned region can be created using with 'partition by prefix' via 
> cache.xml
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Done:
Code is reviewed and checked in
Tests are created and pass

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.


  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.



> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Done:
> Code is reviewed and checked in
> Tests are created and pass
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Created] (GEODE-3016) A developer can create a Region with Partition by Prefix using Cache XML

[Fred Krone (JIRA)]

Fred Krone created GEODE-3016:
-

 Summary: A developer can create a Region with Partition by Prefix 
using Cache XML
 Key: GEODE-3016
 URL: https://issues.apache.org/jira/browse/GEODE-3016
 Project: Geode
  Issue Type: Sub-task
  Components: regions
Reporter: Fred Krone


A user should be able to set partition by prefix when creating a partitioned 
region with cache.xml.

This can only be done when creating a Region type Partition

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
Only String keys work – all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
When partition-by-prefix is set AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.

Optional: A key with no delimiter throws an error




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

Re: Review Request 59643: GEODE-3006: reduce the frequency of ping request and reduce the loglevel of login/logout messages

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On May 31, 2017, 10:46 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59643/
> ---
> 
> (Updated May 31, 2017, 10:46 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> disregard the diff for log4j2.xml changes, these are from the changeset of 
> another review request.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java
>  b342c6688e527b0ed67e0210c6f8befa15978818 
> 
> 
> Diff: https://reviews.apache.org/r/59643/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59643: GEODE-3006: reduce the frequency of ping request and reduce the loglevel of login/logout messages

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On May 31, 2017, 10:46 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59643/
> ---
> 
> (Updated May 31, 2017, 10:46 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> disregard the diff for log4j2.xml changes, these are from the changeset of 
> another review request.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java
>  b342c6688e527b0ed67e0210c6f8befa15978818 
> 
> 
> Diff: https://reviews.apache.org/r/59643/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 59643: GEODE-3006: reduce the frequency of ping request and reduce the loglevel of login/logout messages

[Jinmei Liao]

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

(Updated May 31, 2017, 10:46 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

disregard the diff for log4j2.xml changes, these are from the changeset of 
another review request.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/shell/AbstractHttpOperationInvoker.java
 b342c6688e527b0ed67e0210c6f8befa15978818 


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


Testing
---

precheckin running


Thanks,

Jinmei Liao

Re: Review Request 59686: GEODE-2983: correctly handling --J option value that has ", " inside.

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On May 31, 2017, 10:44 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59686/
> ---
> 
> (Updated May 31, 2017, 10:44 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2983: correctly handling --J option value that has "," inside.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  288ea054ae1230c480d141c0159d6ccf9c299a7d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  4467792f60a2a3bf7cc53cf35e997e7462882539 
> 
> 
> Diff: https://reviews.apache.org/r/59686/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59686: GEODE-2983: correctly handling --J option value that has ", " inside.

[Jinmei Liao]

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

(Updated May 31, 2017, 10:44 p.m.)


Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2983: correctly handling --J option value that has "," inside.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
 288ea054ae1230c480d141c0159d6ccf9c299a7d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
 4467792f60a2a3bf7cc53cf35e997e7462882539 


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

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


Testing
---

precheckin running


Thanks,

Jinmei Liao

Re: Review Request 59686: GEODE-2983: correctly handling --J option value that has ", " inside.

[Ken Howe]

> On May 31, 2017, 10:18 p.m., Jared Stewart wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
> > Lines 48 (patched)
> > 
> >
> > I worry that a user may at some point specify a `--J` option that 
> > includes `,,`.  I think our code could be more robust by using a delimeter 
> > that a user can't type on a standard keyboard.  The ASCII "Unit separator" 
> > character (decimal code 31, hex 0x1f) seems like a natural candidate.  That 
> > would make this look like: 
> > 
> > ```
> >   private static final char ASCII_UNIT_SEPARATOR = '\u001F';
> >   public static final String JARGUMENT_SPLIREGX = "" + 
> > ASCII_UNIT_SEPARATOR;
> > ```
> > 
> > 
> > I also think that `J_ARGUMENT_DELIMITER` might be a more informative 
> > name.

+1


- Ken


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


On May 31, 2017, 5:42 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59686/
> ---
> 
> (Updated May 31, 2017, 5:42 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2983: correctly handling --J option value that has "," inside.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  288ea054ae1230c480d141c0159d6ccf9c299a7d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  4467792f60a2a3bf7cc53cf35e997e7462882539 
> 
> 
> Diff: https://reviews.apache.org/r/59686/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Review Request 59643: GEODE-3006: reduce the frequency of ping request and reduce the loglevel of login/logout messages

[Jared Stewart]

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



I don't see any diff associated with this review request.  Can you make sure it 
was attached properly?

- Jared Stewart


On May 30, 2017, 6:16 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59643/
> ---
> 
> (Updated May 30, 2017, 6:16 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> disregard the diff for log4j2.xml changes, these are from the changeset of 
> another review request.
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Assigned] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-3014:
--

Assignee: Karen Smoler Miller

> Document gfsh create lucene index and region failure sequence
> -
>
> Key: GEODE-3014
> URL: https://issues.apache.org/jira/browse/GEODE-3014
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Barry Oglesby
>Assignee: Karen Smoler Miller
>
> When creating a lucene index and region using gfsh, there is a specific 
> command sequence that causes the region to not be created successfully.
> The sequence that fails is:
> - start server(s)
> - create lucene index
> - start additional server(s)
> - create region
> What fails about this sequence is the lucene index is not saved in cluster 
> configuration until after the region is created. Before the region is 
> created, its only saved locally in existing servers. Since new servers don't 
> have the index when the region is created, the index definitions aren't 
> consistent across servers. This causes the region to be created only in some 
> servers (either all the original ones with the index or all the new ones 
> without the index).
> An alternate sequence that succeeds is:
> - start server(s)
> - create lucene index
> - create region
> - start additional server(s)
> Once the region has been created, then both the lucene index and region are 
> saved in cluster configuration, so new servers will create both the region 
> and index.



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

Re: Review Request 59686: GEODE-2983: correctly handling --J option value that has ", " inside.

[Jared Stewart]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
Lines 48 (patched)


I worry that a user may at some point specify a `--J` option that includes 
`,,`.  I think our code could be more robust by using a delimeter that a user 
can't type on a standard keyboard.  The ASCII "Unit separator" character 
(decimal code 31, hex 0x1f) seems like a natural candidate.  That would make 
this look like: 

```
  private static final char ASCII_UNIT_SEPARATOR = '\u001F';
  public static final String JARGUMENT_SPLIREGX = "" + ASCII_UNIT_SEPARATOR;
```

I also think that `J_ARGUMENT_DELIMITER` might be a more informative name.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
Lines 233 (patched)


What do you think about adding a field to `GfshParser` that can be 
referenced by all of these `optionContexts`?  Basically:

```

class GfshParser { 
... 
J_ARGUMENT_OPTION_CONTEXT = "splittingRegex=" + JARGUMENT_SPLIREGX;
}
```

```
 @CliOption(key = CliStrings.START_LOCATOR__J,
  optionContext = GfshParser.J_ARGUMENT_OPTION_CONTEXT,
  help = CliStrings.START_LOCATOR__J__HELP) final String[] 
jvmArgsOpts,
```


- Jared Stewart


On May 31, 2017, 5:42 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59686/
> ---
> 
> (Updated May 31, 2017, 5:42 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2983: correctly handling --J option value that has "," inside.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/GfshParser.java
>  288ea054ae1230c480d141c0159d6ccf9c299a7d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  74acfd6e03613ac4d0c62fcdd4ea859d1c74d2f2 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/GfshParserParsingTest.java
>  4467792f60a2a3bf7cc53cf35e997e7462882539 
> 
> 
> Diff: https://reviews.apache.org/r/59686/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin running
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[jira] [Resolved] (GEODE-3011) gfsh example to do a Lucene query is incorrect

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-3011.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
> Fix For: 1.2.0
>
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[jira] [Commented] (GEODE-3011) gfsh example to do a Lucene query is incorrect

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-3011:


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

GEODE-3011 Correct a Lucene gfsh query example

This closes #553


> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[jira] [Commented] (GEODE-3011) gfsh example to do a Lucene query is incorrect

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[GitHub] geode pull request #553: GEODE-3011 Correct a Lucene gfsh query example

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-3011) gfsh example to do a Lucene query is incorrect

[ASF GitHub Bot (JIRA)]

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

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

Github user joeymcallister commented on the issue:

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


> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[GitHub] geode issue #553: GEODE-3011 Correct a Lucene gfsh query example

[joeymcallister]

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/553
  
+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] [Resolved] (GEODE-2994) Doc task: interactions of backups with persistence

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2994.

   Resolution: Fixed
Fix Version/s: 1.2.0

> 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
> Fix For: 1.2.0
>
>
> 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)

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

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2994:


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

GEODE-2994 Take backups when region ops are quiescent

This closes #544


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

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2994) Doc task: interactions of backups with persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/544
  
+1, looks good.

On Wed, May 31, 2017 at 2:46 PM, Barrett Oglesby 
wrote:

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

> .
>



> 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 issue #544: GEODE-2994 Take backups when region ops are quiescent

[dihardman]

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/544
  
+1, looks good.

On Wed, May 31, 2017 at 2:46 PM, Barrett Oglesby 
wrote:

> *@boglesby* approved this pull request.
>
> —
> 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 59692: GEODE-2925: add target for resource operation for finer grained security

[Ken Howe]

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




geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java
Line 77 (original), 95 (patched)


I think it would be better to use Region.SEPARATOR instead of "/".


- Ken Howe


On May 31, 2017, 8:55 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated May 31, 2017, 8:55 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2925: add target for resource operation for finer grained security
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  600d5462b1d18cfc702d400f6d91c1ac1fab3755 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a87b558772902cf14580f3e14fca97b3 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da464419779773c9116d824fcf11774bafbd79 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271efb876d471b35e002c5b110919f10fcc 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481660
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -294,8 +294,11 @@ will return `object_2`.
 will return `object_3`.
 - Backups should only be made for regions with Lucene indexes
 when there are no puts, updates, or deletes in progress.
-Incremental backups will not be consistent for the region and
-its index upon restart if these operations were in progress,
-due to the delayed processing associated with the asynchronous event queue.
-If region data needs to be restored from a backup,
-follow the same procedure as given for changing an index.
+A backup might cause an inconsistency between region data and a Lucene 
index,
+if that backup is used to restore a system.
+The Lucene index is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the Lucene index
+(causing a disk operation),
+then the backup represents inconsistent data in the region and Lucene 
index.
--- End diff --

Reworded.


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481618
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

Reworded.  


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

[karensmolermiller]

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481660
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -294,8 +294,11 @@ will return `object_2`.
 will return `object_3`.
 - Backups should only be made for regions with Lucene indexes
 when there are no puts, updates, or deletes in progress.
-Incremental backups will not be consistent for the region and
-its index upon restart if these operations were in progress,
-due to the delayed processing associated with the asynchronous event queue.
-If region data needs to be restored from a backup,
-follow the same procedure as given for changing an index.
+A backup might cause an inconsistency between region data and a Lucene 
index,
+if that backup is used to restore a system.
+The Lucene index is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the Lucene index
+(causing a disk operation),
+then the backup represents inconsistent data in the region and Lucene 
index.
--- End diff --

Reworded.


---
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 pull request #544: GEODE-2994 Take backups when region ops are quiesce...

[karensmolermiller]

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481618
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

Reworded.  


---
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-2994) Doc task: interactions of backups with persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481506
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
--- End diff --

Done.


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

[karensmolermiller]

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481506
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
--- End diff --

Done.


---
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-2994) Doc task: interactions of backups with persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481045
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the AEQ (causing a disk operation),
+then the backup represents inconsistent data in the region and the AEQ.
--- End diff --

Could you please create a new JIRA if you want to refine the restoration 
procedure?  I think that we ought to be much more specific about how to destroy 
any queue.

I'd like this JIRA to just make sure to warn users about the possibility of 
inconsistency in their backups.


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

[karensmolermiller]

Github user karensmolermiller commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119481045
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the AEQ (causing a disk operation),
+then the backup represents inconsistent data in the region and the AEQ.
--- End diff --

Could you please create a new JIRA if you want to refine the restoration 
procedure?  I think that we ought to be much more specific about how to destroy 
any queue.

I'd like this JIRA to just make sure to warn users about the possibility of 
inconsistency in their backups.


---
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-3011) gfsh example to do a Lucene query is incorrect

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/553
  
+1 looks good!

On Wed, May 31, 2017 at 1:33 PM, Karen Miller 
wrote:

> @dihardman  @boglesby
>  @upthewaterspout
>  @ladyVader
>  @nabarunnag 
> @DivineEnder  @jhuynh1
>  @davebarnes97
>  @joeymcallister
> 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/553
> Commit Summary
>
>- GEODE-3011 Correct a Lucene gfsh query example
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (4)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/553.patch
>- https://github.com/apache/geode/pull/553.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 

> .
>



> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[GitHub] geode issue #553: GEODE-3011 Correct a Lucene gfsh query example

[dihardman]

Github user dihardman commented on the issue:

https://github.com/apache/geode/pull/553
  
+1 looks good!

On Wed, May 31, 2017 at 1:33 PM, Karen Miller 
wrote:

> @dihardman  @boglesby
>  @upthewaterspout
>  @ladyVader
>  @nabarunnag 
> @DivineEnder  @jhuynh1
>  @davebarnes97
>  @joeymcallister
> 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/553
> Commit Summary
>
>- GEODE-3011 Correct a Lucene gfsh query example
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (4)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/553.patch
>- https://github.com/apache/geode/pull/553.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.
---

Review Request 59692: GEODE-2925: add target for resource operation for finer grained security

[Jinmei Liao]

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

Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
Patrick Rhomberg.


Repository: geode


Description
---

GEODE-2925: add target for resource operation for finer grained security


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 600d5462b1d18cfc702d400f6d91c1ac1fab3755 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 226cfaf45fa2a1720a92e8e7ac2c179653240e2d 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 


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


Testing
---

precheckin runing


Thanks,

Jinmei Liao

[jira] [Commented] (GEODE-3011) gfsh example to do a Lucene query is incorrect

[ASF GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-3011 Correct a Lucene gfsh query example

@dihardman @boglesby @upthewaterspout @ladyVader @nabarunnag @DivineEnder 
@jhuynh1 @davebarnes97 @joeymcallister 
Please review.

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

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

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

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


commit 9ddafd9428bf6084915b8e53ae1cad13b28bae90
Author: Karen Miller 
Date:   2017-05-31T20:28:28Z

GEODE-3011 Correct a Lucene gfsh query example




> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[GitHub] geode pull request #553: GEODE-3011 Correct a Lucene gfsh query example

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-3011 Correct a Lucene gfsh query example

@dihardman @boglesby @upthewaterspout @ladyVader @nabarunnag @DivineEnder 
@jhuynh1 @davebarnes97 @joeymcallister 
Please review.

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

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

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

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


commit 9ddafd9428bf6084915b8e53ae1cad13b28bae90
Author: Karen Miller 
Date:   2017-05-31T20:28:28Z

GEODE-3011 Correct a Lucene gfsh query example




---
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-3015) CI Failure: ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient

[Eric Shu (JIRA)]

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

Eric Shu updated GEODE-3015:

Labels: ci  (was: )

> CI Failure: 
> ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient
> 
>
> Key: GEODE-3015
> URL: https://issues.apache.org/jira/browse/GEODE-3015
> Project: Geode
>  Issue Type: Bug
>  Components: transactions
>Reporter: Eric Shu
>  Labels: ci
>
> Failed in CI run: GemFireDistributedTest #664
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest > 
> testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest$$Lambda$56/988223363.run
>  in VM 0 running on Host 56abe8be984c with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
> at 
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient(ClientServerTransactionDUnitTest.java:3985)
> Caused by:
> java.lang.AssertionError: expected:<0> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at 
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.verifyTXStateEmpty(ClientServerTransactionDUnitTest.java:3992)
> at 
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.lambda$testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient$c002f5a9$1(ClientServerTransactionDUnitTest.java:3985)
> {noformat}



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

[jira] [Created] (GEODE-3015) CI Failure: ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient

[Eric Shu (JIRA)]

Eric Shu created GEODE-3015:
---

 Summary: CI Failure: 
ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient
 Key: GEODE-3015
 URL: https://issues.apache.org/jira/browse/GEODE-3015
 Project: Geode
  Issue Type: Bug
  Components: transactions
Reporter: Eric Shu


Failed in CI run: GemFireDistributedTest #664
{noformat}

org.apache.geode.internal.cache.ClientServerTransactionDUnitTest > 
testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.ClientServerTransactionDUnitTest$$Lambda$56/988223363.run
 in VM 0 running on Host 56abe8be984c with 4 VMs
at org.apache.geode.test.dunit.VM.invoke(VM.java:377)
at org.apache.geode.test.dunit.VM.invoke(VM.java:347)
at org.apache.geode.test.dunit.VM.invoke(VM.java:292)
at 
org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient(ClientServerTransactionDUnitTest.java:3985)

Caused by:
java.lang.AssertionError: expected:<0> but was:<1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.verifyTXStateEmpty(ClientServerTransactionDUnitTest.java:3992)
at 
org.apache.geode.internal.cache.ClientServerTransactionDUnitTest.lambda$testTXStateCleanedUpIfJTABeforeCompletionFailedOnClient$c002f5a9$1(ClientServerTransactionDUnitTest.java:3985)
{noformat}



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

[jira] [Assigned] (GEODE-3011) gfsh example to do a Lucene query is incorrect

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-3011:
--

Assignee: Karen Smoler Miller

> gfsh example to do a Lucene query is incorrect
> --
>
> Key: GEODE-3011
> URL: https://issues.apache.org/jira/browse/GEODE-3011
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Diane Hardman
>Assignee: Karen Smoler Miller
>
> In the Lucene integration section of the docs is the following incorrect gfsh 
> command example:
> gfsh> lucene search --regionName=/orders -queryStrings="John*" 
> --defaultField=field1
> Instead it should be:
> gfsh> search lucene --name=indexName --region=/orders --queryStrings="John*" 
> --defaultField=customer --limit=100



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error
When partition-by-prefix is 'on' AND the user also sets a specific partition 
resolver (an implemented class), partitioning should default to the implemented 
class.


  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error



> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error
> When partition-by-prefix is 'on' AND the user also sets a specific partition 
> resolver (an implemented class), partitioning should default to the 
> implemented class.



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

[jira] [Created] (GEODE-3014) Document gfsh create lucene index and region failure sequence

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-3014:


 Summary: Document gfsh create lucene index and region failure 
sequence
 Key: GEODE-3014
 URL: https://issues.apache.org/jira/browse/GEODE-3014
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: Barry Oglesby


When creating a lucene index and region using gfsh, there is a specific command 
sequence that causes the region to not be created successfully.

The sequence that fails is:

- start server(s)
- create lucene index
- start additional server(s)
- create region

What fails about this sequence is the lucene index is not saved in cluster 
configuration until after the region is created. Before the region is created, 
its only saved locally in existing servers. Since new servers don't have the 
index when the region is created, the index definitions aren't consistent 
across servers. This causes the region to be created only in some servers 
(either all the original ones with the index or all the new ones without the 
index).

An alternate sequence that succeeds is:

- start server(s)
- create lucene index
- create region
- start additional server(s)

Once the region has been created, then both the lucene index and region are 
saved in cluster configuration, so new servers will create both the region and 
index.




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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition by Prefix using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Summary: A developer can create a Region with Partition by Prefix using 
Java API  (was: A developer can create a Region with Partition Resolution using 
Java API)

> A developer can create a Region with Partition by Prefix using Java API
> ---
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error



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

[jira] [Updated] (GEODE-3005) A developer can create a Region with Partition Resolution using Java API

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3005:
--
Description: 
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type Partition

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error


  was:
A user should be able to set partition by prefix programmatically when creating 
a partitioned region.

This can only be done when creating a Region type PARTITION

Acceptance: 
Partitioned region can be created using new 'partition by prefix' attributes 
(on/off, delimiter) 
Only String keys work -- all other keys throw an error
Providing a key with the correct delimiter routes the entry to the correct node
Providing a key with no delimiter throws an error



> A developer can create a Region with Partition Resolution using Java API
> 
>
> Key: GEODE-3005
> URL: https://issues.apache.org/jira/browse/GEODE-3005
> Project: Geode
>  Issue Type: Wish
>  Components: regions
>Reporter: Fred Krone
>Assignee: Fred Krone
>
> A user should be able to set partition by prefix programmatically when 
> creating a partitioned region.
> This can only be done when creating a Region type Partition
> Acceptance: 
> Partitioned region can be created using new 'partition by prefix' attributes 
> (on/off, delimiter) 
> Only String keys work -- all other keys throw an error
> Providing a key with the correct delimiter routes the entry to the correct 
> node
> Providing a key with no delimiter throws an error



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119445495
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -294,8 +294,11 @@ will return `object_2`.
 will return `object_3`.
 - Backups should only be made for regions with Lucene indexes
 when there are no puts, updates, or deletes in progress.
-Incremental backups will not be consistent for the region and
-its index upon restart if these operations were in progress,
-due to the delayed processing associated with the asynchronous event queue.
-If region data needs to be restored from a backup,
-follow the same procedure as given for changing an index.
+A backup might cause an inconsistency between region data and a Lucene 
index,
+if that backup is used to restore a system.
+The Lucene index is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the Lucene index
+(causing a disk operation),
+then the backup represents inconsistent data in the region and Lucene 
index.
--- End diff --

See comments added to backup_restore_disk_store.erb


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

[dihardman]

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119445495
  
--- Diff: geode-docs/tools_modules/lucene_integration.html.md.erb ---
@@ -294,8 +294,11 @@ will return `object_2`.
 will return `object_3`.
 - Backups should only be made for regions with Lucene indexes
 when there are no puts, updates, or deletes in progress.
-Incremental backups will not be consistent for the region and
-its index upon restart if these operations were in progress,
-due to the delayed processing associated with the asynchronous event queue.
-If region data needs to be restored from a backup,
-follow the same procedure as given for changing an index.
+A backup might cause an inconsistency between region data and a Lucene 
index,
+if that backup is used to restore a system.
+The Lucene index is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the Lucene index
+(causing a disk operation),
+then the backup represents inconsistent data in the region and Lucene 
index.
--- End diff --

See comments added to backup_restore_disk_store.erb


---
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] [Comment Edited] (GEODE-2979) Adding server after defining Lucene index results in unusable cluster

[Barry Oglesby (JIRA)]

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

Barry Oglesby edited comment on GEODE-2979 at 5/31/17 7:01 PM:
---

Creating an index currently just creates an entry in each existing member's 
LuceneServiceImpl definedIndexMap. This is an in-memory map. There is no entry 
in cluster config. The lucene index element has to be created in the context of 
a region element. Currently, there isn't any mechanism for creating an 
unattached element which is basically what an index without a region is.

If the lucene indexes are listed, the existing members show the Status as 
Defined. That means the region hasn't been created yet.
{noformat}
gfsh>list lucene indexes
Index Name | Region Path | Server Name | Indexed Fields | 
Field Analyzer  | Status
-- | --- | --- | -- | 
--- | ---
testIndex  | /testRegion | server1 | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Defined
{noformat}
In this case, if another member is started, it will not get the index 
definition since it is not saved in cluster config nor is there a message 
between the members exchanging defined indexes.

If the region is created in this scenario, then only one of the servers will 
successfully create it.
{noformat}
gfsh>create region --name=testRegion --type=PARTITION_REDUNDANT_PERSISTENT
Member  | Status
--- | 

server2 | ERROR: Must create Lucene index testIndex on region /testRegion 
because it is defined in another member.
server1 | Region "/testRegion" created on "server1"
{noformat}
When the region is created, the defined indexes for it are then created and an 
element like this is added to cluster config:
{noformat}




http://geode.apache.org/schema/lucene; 
name="testIndex">



{noformat}
Any member started after the region element is in cluster config will get the 
region and index. The Initialized Status means that the region has been created.
{noformat}
gfsh>list lucene indexes
Index Name | Region Path | Server Name | Indexed Fields | 
Field Analyzer  | Status
-- | --- | --- | -- | 
--- | ---
testIndex  | /testRegion | server1 | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Initialized
testIndex  | /testRegion | server2 | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Initialized
{noformat}
So, this sequence fails:

- start server
- create index
- start other server
- create region

This sequence succeeds:

- start server
- create index
- create region
- start other server

In order to make the first scenario successful, we would have to either:

- persist the index definition in the cluster config so that when other members 
start, they get all the defined indexes and create them when the region is 
created
- pass LuceneService defined indexes between members at startup. Maybe the 
CacheServiceProfile should be exchanged in its own message instead of as part 
of the CacheProfile (which is for a region) as it is now.



was (Author: barry.oglesby):
Creating an index currently just creates an entry in each existing member's 
LuceneServiceImpl definedIndexMap. This is an in-memory map. There is no entry 
in cluster config. The lucene index element has to be created in the context of 
a region element. Currently, there isn't any mechanism for creating an 
unattached element which is basically what an index without a region is.

If the lucene indexes are listed, the existing members show the Status as 
Defined. That means the region hasn't been created yet.
{noformat}
gfsh>list lucene indexes
Index Name | Region Path | Server Name | Indexed Fields | 
Field Analyzer  | Status
-- | --- | --- | -- | 
--- | ---
testIndex  | /testRegion | server1 | [__REGION_VALUE_FIELD] | 
{__REGION_VALUE_FIELD=StandardAnalyzer} | Defined
{noformat}
In this case, if another member is started, it will not get the index 
definition since it is not saved in cluster config nor is there a message 
between the members exchanging defined indexes.

If the region is created in this scenario, then only one of the servers will 
successfully create it.
{noformat}
gfsh>create region --name=testRegion --type=PARTITION_REDUNDANT_PERSISTENT
Member  | Status
--- | 

server2 | ERROR: Must create Lucene index 

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

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119445110
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the AEQ (causing a disk operation),
+then the backup represents inconsistent data in the region and the AEQ.
--- End diff --

Add a workaround strategy:
If this backup must be used to restore your system, consider the region 
data as the valid system of record, destroy the AEQ, export the region data, 
remove all data from the region and re-import it using the command line option 
invoking listeners. This will re-create the AEQ in a consistent state with the 
region data.


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

[dihardman]

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119445110
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
+a persisted write to a region (causing a disk operation)
+and the resulting persisted write to the AEQ (causing a disk operation),
+then the backup represents inconsistent data in the region and the AEQ.
--- End diff --

Add a workaround strategy:
If this backup must be used to restore your system, consider the region 
data as the valid system of record, destroy the AEQ, export the region data, 
remove all data from the region and re-import it using the command line option 
invoking listeners. This will re-create the AEQ in a consistent state with the 
region data.


---
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-2994) Doc task: interactions of backups with persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user boglesby commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119441378
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

I think Diane captured some of this already.

I'm not sure I understand the formatting in this passage. I'm looking at it 
on github, though, so maybe thats why. I'm not sure I understand this sentence: 
"The AEQ is persistent." Is it meant to emphasize both the region and queue are 
persistent and writes to them are not atomic?

asyncronous -> asynchronous

Its not just AEQs that could be inconsistent. Also WAN GatewaySenders. They 
both use the same queueing code underneath the covers. Its the persistent queue 
that could be out of sync with the persistent data region, so both AEQs and WAN 
GatewaySenders can have the same issue.



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

[boglesby]

Github user boglesby commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119441378
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

I think Diane captured some of this already.

I'm not sure I understand the formatting in this passage. I'm looking at it 
on github, though, so maybe thats why. I'm not sure I understand this sentence: 
"The AEQ is persistent." Is it meant to emphasize both the region and queue are 
persistent and writes to them are not atomic?

asyncronous -> asynchronous

Its not just AEQs that could be inconsistent. Also WAN GatewaySenders. They 
both use the same queueing code underneath the covers. Its the persistent queue 
that could be out of sync with the persistent data region, so both AEQs and WAN 
GatewaySenders can have the same issue.



---
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 pull request #544: GEODE-2994 Take backups when region ops are quiesce...

[dihardman]

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119439870
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

Instead of "If the backup is unlucky enough to be taken between", consider:
If the timing of the backup occurs between...


---
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-2994) Doc task: interactions of backups with persistence

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119439870
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
+The AEQ is persistent.
+If a backup is unlucky enough to be taken between
--- End diff --

Instead of "If the backup is unlucky enough to be taken between", consider:
If the timing of the backup occurs between...


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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119438727
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
--- End diff --

I recommend taking out the clause "if that backup were to be used to 
restore a system". The explanation that follows fully explains this.


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

[dihardman]

Github user dihardman commented on a diff in the pull request:

https://github.com/apache/geode/pull/544#discussion_r119438727
  
--- Diff: 
geode-docs/managing/disk_storage/backup_restore_disk_store.html.md.erb ---
@@ -38,6 +38,15 @@ Do not try to create backup files from a running system 
by using your operating
 **Preparing to Make a Backup**
 
 -   Consider compacting your disk store before making a backup. If 
auto-compaction is turned off, you may want to do a manual compaction to save 
on the quantity of data copied over the network by the backup. For more 
information on configuring a manual compaction, see [Manual 
Compaction](compacting_disk_stores.html#compacting_disk_stores__li_63CF8C35153D4173AADF7DC35FEC61F9).
+-   Take the backup when region operations are quiescent,
+to avoid the possibility of an inconsistency between region data and
+an asyncronous event queue (AEQ),
+if that backup were to be used to restore a system.
--- End diff --

I recommend taking out the clause "if that backup were to be used to 
restore a system". The explanation that follows fully explains this.


---
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-3013) Reduce logging level for FunctionExceptions : InternalFunctionInvocationTargetException: Multiple target nodes found for single hop operation

[ASF GitHub Bot (JIRA)]

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

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

GitHub user ladyVader opened a pull request:

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

GEODE-3013: Reduce log level for FunctionInvocationTargetException

GEODE-3013: Reduce log level for FunctionInvocationTargetExceptions

- Modified to display at debug vs. warning level (includes full stack trace)

@upthewaterspout @nabarunnag, @boglesby, @jhuynh1, @gesterzhou

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

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

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

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] 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)?

### 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/apache/geode feature/GEODE-3013

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

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


commit d9f219ad048668a99ccdf4ac630326c1e13c6f19
Author: Lynn Hughes-Godfrey 
Date:   2017-05-31T01:16:34Z

GEODE-3013: Reduce logging level for FunctionInvocationTargetException: 
Multiple target nodes found for single hop operation

- Modified to display at debug vs. warning level




> Reduce logging level for FunctionExceptions : 
> InternalFunctionInvocationTargetException: Multiple target nodes found for 
> single hop operation
> -
>
> Key: GEODE-3013
> URL: https://issues.apache.org/jira/browse/GEODE-3013
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Shelley Lynn Hughes-Godfrey
>
> The following exception should not be logged as a warning with a full stack 
> dump (as it is not actionable by the user).
> Changing this to debug log level.
> {noformat}
> Multiple target nodes found for single hop operation
> [warning 2017/04/04 14:53:06.031 PDT bridgegemfire1_monaco_15778 
>  tid=0x98] Exception on server while 
> executing function : 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
>  Multiple target nodes found for single hop operation
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeOnBucketSet(PartitionedRegion.java:3684)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.executeFunction(PartitionedRegion.java:3344)
> at 
> org.apache.geode.internal.cache.execute.PartitionedRegionFunctionExecutor.executeFunction(PartitionedRegionFunctionExecutor.java:225)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:563)
> at 
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionSingleHop.cmdExecute(ExecuteRegionFunctionSingleHop.java:264)
> at 
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:141)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:783)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:914)
> at 
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1171)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> 

[GitHub] geode pull request #552: GEODE-3013: Reduce log level for FunctionInvocation...

[ladyVader]

GitHub user ladyVader opened a pull request:

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

GEODE-3013: Reduce log level for FunctionInvocationTargetException

GEODE-3013: Reduce log level for FunctionInvocationTargetExceptions

- Modified to display at debug vs. warning level (includes full stack trace)

@upthewaterspout @nabarunnag, @boglesby, @jhuynh1, @gesterzhou

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:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in 
the commit message?

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

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

- [ ] Does `gradlew build` run cleanly?

- [ ] Have you written or updated unit tests to verify your changes?

- [ ] 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)?

### 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/apache/geode feature/GEODE-3013

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

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


commit d9f219ad048668a99ccdf4ac630326c1e13c6f19
Author: Lynn Hughes-Godfrey 
Date:   2017-05-31T01:16:34Z

GEODE-3013: Reduce logging level for FunctionInvocationTargetException: 
Multiple target nodes found for single hop operation

- Modified to display at debug vs. warning level




---
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 59642: GEODE-3000: do not have jetty log at debug level

[Emily Yeh]

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




geode-core/src/test/java/org/apache/geode/management/internal/security/LogNoPasswordTest.java
Lines 55-59 (patched)


Perhaps the Scanner should be closed? Just adding `scanner.close()` after 
the while loop should do it. (Alternatively, scanner could be instantiated 
before the `for` loop, so that it doesn't have to be re-instantiated during 
every iteration.)


- Emily Yeh


On May 31, 2017, 5:45 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59642/
> ---
> 
> (Updated May 31, 2017, 5:45 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-3000: do not have jetty log at debug level
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/resources/log4j2.xml 
> cdb932b5b3b3337aae4a6cde9800ebd5617a0c4d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/LogNoPasswordTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59642/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin successful
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>