Re: [DISCUSS] easy string based partitioning

[Jacob Barrett]

The "simplest implementation" overlooks the rational for implementing it.
The rational was to avoid customers having to implement classes to do
partitioning. How is that any different than forcing them to conform their
string keys to a very specific format we can parse in this solution. If
there keys already have multiple components and is represented already in a
string then why force them to change their code?

How is regex any more complicated in the simplest case? The regex
/^([^:]+):/ matches the proposed "partition:key" format.

-Jake



On Fri, Jun 2, 2017 at 8:57 PM Michael Stolz  wrote:

> We are looking for the simplest implementation.  Not the best. Fixed
> delimeter, string only, SIMPLE.
>
> We as a team have a habit of always solving the bigger problem.
>
> Lets allow this one to be simple.
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771 <(631)%20835-4771>
>
> On Jun 2, 2017 10:16 PM, "Jacob Barrett"  wrote:
>
> > If you implement as regular expression the user doesn't have to reformat
> > their key to a specific format (akin to making them implement a class). I
> > would concat the matching groups for generate the routing key.
> >
> > Consider RegEx: .*\bcorrelation=(\d+).*\bmaybe-something-else=(\w)
> > With Keys:
> > A: my,key;with:any-chars;unique=12345;correlation=678/and,
> > maybe-something-else=a
> > B: my,key;unique=876324;correlation=678;and,maybe-something-else=a,foo
> > C: somthing;different=988975;correlation=678;then,maybe-something-else=ba
> >
> > Keys A and B would have routing key '678a'. Key C would have routing key
> > '678b'.
> >
> > -Jake
> >
> >
> >
> > Consider
> >
> > On Fri, Jun 2, 2017 at 4:02 PM Darrel Schneider 
> > wrote:
> >
> > > Geode partitioned regions usually partition the data based on the key's
> > > hashcode.
> > > You can do your own partitioning by implementing the PartitionResolver
> > > interface and configuring it on the partitioned region.
> > >
> > > In some use cases needing to deploy your class that implements
> > > PartitionResolver can be problematic so we would like to find a way to
> > > offer partitioning based on a portion of the key (instead of the
> default
> > > which uses the entire key) that does not require you to implement your
> > own
> > > PartitionResolver and does not require you to deploy your own code to
> do
> > > the custom partitioning.
> > >
> > > Another group of users that do not want to implement PartitionResolver
> > are
> > > non-java clients. So the solution is required to be usable by non-java
> > > geode clients without needing to reimplement the client to support a
> new
> > > feature.
> > >
> > > Another constraint on the solution is for it to be both easy to use and
> > > easy to implement.
> > >
> > > The proposed solution is to provide a class named:
> > > org.apache.geode.cache.StringPrefixPartitionResolver
> > > This class will implement PartitionResolver and have a default
> > constructor.
> > > To use it you need to configure a partitioned region's
> PartitionResolver
> > > using the already existing mechanism for this (api, gfsh, or xml).
> > > The StringPrefixPartitionResolver will require all keys on its region
> to
> > be
> > > of type String.
> > > It also requires that the string key contains at least one ':'
> character.
> > > The substring of the key that precedes the first ':' is the prefix that
> > > will be returned from "getRoutingObject".
> > >
> > > An example of doing this in gfsh is:
> > > create region --name=r1 --type=PARTITION
> > > --partition-resolver=org.apache.geode.cache.
> > StringPrefixPartitionResolver
> > >
> > > Note that attempting to use a key that is not a String or does not
> > contain
> > > a ':' will throw an exception. This is to help developers realize they
> > made
> > > a mistake.
> > >
> > > Note that the delimiter is always a ':'. It would be easy to made the
> > > delimiter configurable when using apis or xml but currently gfsh does
> not
> > > provide a way to pass parameters to the --partition-resolver create
> > region
> > > option.
> > >
> > > The only public api change this proposal makes is the new
> > > StringPrefixPartitionResolver class.
> > >
> >
>

Re: [DISCUSS] easy string based partitioning

[Michael Stolz]

We are looking for the simplest implementation.  Not the best. Fixed
delimeter, string only, SIMPLE.

We as a team have a habit of always solving the bigger problem.

Lets allow this one to be simple.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Jun 2, 2017 10:16 PM, "Jacob Barrett"  wrote:

> If you implement as regular expression the user doesn't have to reformat
> their key to a specific format (akin to making them implement a class). I
> would concat the matching groups for generate the routing key.
>
> Consider RegEx: .*\bcorrelation=(\d+).*\bmaybe-something-else=(\w)
> With Keys:
> A: my,key;with:any-chars;unique=12345;correlation=678/and,
> maybe-something-else=a
> B: my,key;unique=876324;correlation=678;and,maybe-something-else=a,foo
> C: somthing;different=988975;correlation=678;then,maybe-something-else=ba
>
> Keys A and B would have routing key '678a'. Key C would have routing key
> '678b'.
>
> -Jake
>
>
>
> Consider
>
> On Fri, Jun 2, 2017 at 4:02 PM Darrel Schneider 
> wrote:
>
> > Geode partitioned regions usually partition the data based on the key's
> > hashcode.
> > You can do your own partitioning by implementing the PartitionResolver
> > interface and configuring it on the partitioned region.
> >
> > In some use cases needing to deploy your class that implements
> > PartitionResolver can be problematic so we would like to find a way to
> > offer partitioning based on a portion of the key (instead of the default
> > which uses the entire key) that does not require you to implement your
> own
> > PartitionResolver and does not require you to deploy your own code to do
> > the custom partitioning.
> >
> > Another group of users that do not want to implement PartitionResolver
> are
> > non-java clients. So the solution is required to be usable by non-java
> > geode clients without needing to reimplement the client to support a new
> > feature.
> >
> > Another constraint on the solution is for it to be both easy to use and
> > easy to implement.
> >
> > The proposed solution is to provide a class named:
> > org.apache.geode.cache.StringPrefixPartitionResolver
> > This class will implement PartitionResolver and have a default
> constructor.
> > To use it you need to configure a partitioned region's PartitionResolver
> > using the already existing mechanism for this (api, gfsh, or xml).
> > The StringPrefixPartitionResolver will require all keys on its region to
> be
> > of type String.
> > It also requires that the string key contains at least one ':' character.
> > The substring of the key that precedes the first ':' is the prefix that
> > will be returned from "getRoutingObject".
> >
> > An example of doing this in gfsh is:
> > create region --name=r1 --type=PARTITION
> > --partition-resolver=org.apache.geode.cache.
> StringPrefixPartitionResolver
> >
> > Note that attempting to use a key that is not a String or does not
> contain
> > a ':' will throw an exception. This is to help developers realize they
> made
> > a mistake.
> >
> > Note that the delimiter is always a ':'. It would be easy to made the
> > delimiter configurable when using apis or xml but currently gfsh does not
> > provide a way to pass parameters to the --partition-resolver create
> region
> > option.
> >
> > The only public api change this proposal makes is the new
> > StringPrefixPartitionResolver class.
> >
>

Re: [DISCUSS] easy string based partitioning

[Jacob Barrett]

If you implement as regular expression the user doesn't have to reformat
their key to a specific format (akin to making them implement a class). I
would concat the matching groups for generate the routing key.

Consider RegEx: .*\bcorrelation=(\d+).*\bmaybe-something-else=(\w)
With Keys:
A: my,key;with:any-chars;unique=12345;correlation=678/and,maybe-something-else=a
B: my,key;unique=876324;correlation=678;and,maybe-something-else=a,foo
C: somthing;different=988975;correlation=678;then,maybe-something-else=ba

Keys A and B would have routing key '678a'. Key C would have routing key
'678b'.

-Jake



Consider

On Fri, Jun 2, 2017 at 4:02 PM Darrel Schneider 
wrote:

> Geode partitioned regions usually partition the data based on the key's
> hashcode.
> You can do your own partitioning by implementing the PartitionResolver
> interface and configuring it on the partitioned region.
>
> In some use cases needing to deploy your class that implements
> PartitionResolver can be problematic so we would like to find a way to
> offer partitioning based on a portion of the key (instead of the default
> which uses the entire key) that does not require you to implement your own
> PartitionResolver and does not require you to deploy your own code to do
> the custom partitioning.
>
> Another group of users that do not want to implement PartitionResolver are
> non-java clients. So the solution is required to be usable by non-java
> geode clients without needing to reimplement the client to support a new
> feature.
>
> Another constraint on the solution is for it to be both easy to use and
> easy to implement.
>
> The proposed solution is to provide a class named:
> org.apache.geode.cache.StringPrefixPartitionResolver
> This class will implement PartitionResolver and have a default constructor.
> To use it you need to configure a partitioned region's PartitionResolver
> using the already existing mechanism for this (api, gfsh, or xml).
> The StringPrefixPartitionResolver will require all keys on its region to be
> of type String.
> It also requires that the string key contains at least one ':' character.
> The substring of the key that precedes the first ':' is the prefix that
> will be returned from "getRoutingObject".
>
> An example of doing this in gfsh is:
> create region --name=r1 --type=PARTITION
> --partition-resolver=org.apache.geode.cache.StringPrefixPartitionResolver
>
> Note that attempting to use a key that is not a String or does not contain
> a ':' will throw an exception. This is to help developers realize they made
> a mistake.
>
> Note that the delimiter is always a ':'. It would be easy to made the
> delimiter configurable when using apis or xml but currently gfsh does not
> provide a way to pass parameters to the --partition-resolver create region
> option.
>
> The only public api change this proposal makes is the new
> StringPrefixPartitionResolver class.
>

[jira] [Created] (GEODE-3027) A developer can co-locate two keys on a put

[Fred Krone (JIRA)]

Fred Krone created GEODE-3027:
-

 Summary: A developer can co-locate two keys on a put
 Key: GEODE-3027
 URL: https://issues.apache.org/jira/browse/GEODE-3027
 Project: Geode
  Issue Type: Improvement
  Components: regions
Reporter: Fred Krone
 Fix For: 1.3.0


Provide a way to put co-locate two keys represented in a delimited string

"AccountId:OrderId"

Here ":" is the delimiter.  The String before the delimiter is the routing key. 
 The String after the delimiter is the simple key.

Acceptance
A user configuring a Region with this PartitionResolver implementation gets 
correctly delimited String keys colocated

Keys can only be Strings or error
Delimiter is present ":" or error

Update JavaDocs



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

Re: [DISCUSS] easy string based partitioning

[John Blum]

Hi Darrel-

+1

I am largely still thinking on this one (also from a *Spring* perspective),
but I like your initial concept/idea.  Will provide more feedback in time.

Cheers,
John


On Fri, Jun 2, 2017 at 4:40 PM, Michael Stolz  wrote:

> +1 This is the easiest way to make colocation easy
>
> --
> Mike Stolz
> Principal Engineer - Gemfire Product Manager
> Mobile: 631-835-4771
>
> On Jun 2, 2017 6:55 PM, "Darrel Schneider"  wrote:
>
> > Geode partitioned regions usually partition the data based on the key's
> > hashcode.
> > You can do your own partitioning by implementing the PartitionResolver
> > interface and configuring it on the partitioned region.
> >
> > In some use cases needing to deploy your class that implements
> > PartitionResolver can be problematic so we would like to find a way to
> > offer partitioning based on a portion of the key (instead of the default
> > which uses the entire key) that does not require you to implement your
> own
> > PartitionResolver and does not require you to deploy your own code to do
> > the custom partitioning.
> >
> > Another group of users that do not want to implement PartitionResolver
> are
> > non-java clients. So the solution is required to be usable by non-java
> > geode clients without needing to reimplement the client to support a new
> > feature.
> >
> > Another constraint on the solution is for it to be both easy to use and
> > easy to implement.
> >
> > The proposed solution is to provide a class named:
> > org.apache.geode.cache.StringPrefixPartitionResolver
> > This class will implement PartitionResolver and have a default
> constructor.
> > To use it you need to configure a partitioned region's PartitionResolver
> > using the already existing mechanism for this (api, gfsh, or xml).
> > The StringPrefixPartitionResolver will require all keys on its region to
> be
> > of type String.
> > It also requires that the string key contains at least one ':' character.
> > The substring of the key that precedes the first ':' is the prefix that
> > will be returned from "getRoutingObject".
> >
> > An example of doing this in gfsh is:
> > create region --name=r1 --type=PARTITION
> > --partition-resolver=org.apache.geode.cache.
> StringPrefixPartitionResolver
> >
> > Note that attempting to use a key that is not a String or does not
> contain
> > a ':' will throw an exception. This is to help developers realize they
> made
> > a mistake.
> >
> > Note that the delimiter is always a ':'. It would be easy to made the
> > delimiter configurable when using apis or xml but currently gfsh does not
> > provide a way to pass parameters to the --partition-resolver create
> region
> > option.
> >
> > The only public api change this proposal makes is the new
> > StringPrefixPartitionResolver class.
> >
>



-- 
-John
john.blum10101 (skype)

Re: [DISCUSS] easy string based partitioning

[Michael Stolz]

+1 This is the easiest way to make colocation easy

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771

On Jun 2, 2017 6:55 PM, "Darrel Schneider"  wrote:

> Geode partitioned regions usually partition the data based on the key's
> hashcode.
> You can do your own partitioning by implementing the PartitionResolver
> interface and configuring it on the partitioned region.
>
> In some use cases needing to deploy your class that implements
> PartitionResolver can be problematic so we would like to find a way to
> offer partitioning based on a portion of the key (instead of the default
> which uses the entire key) that does not require you to implement your own
> PartitionResolver and does not require you to deploy your own code to do
> the custom partitioning.
>
> Another group of users that do not want to implement PartitionResolver are
> non-java clients. So the solution is required to be usable by non-java
> geode clients without needing to reimplement the client to support a new
> feature.
>
> Another constraint on the solution is for it to be both easy to use and
> easy to implement.
>
> The proposed solution is to provide a class named:
> org.apache.geode.cache.StringPrefixPartitionResolver
> This class will implement PartitionResolver and have a default constructor.
> To use it you need to configure a partitioned region's PartitionResolver
> using the already existing mechanism for this (api, gfsh, or xml).
> The StringPrefixPartitionResolver will require all keys on its region to be
> of type String.
> It also requires that the string key contains at least one ':' character.
> The substring of the key that precedes the first ':' is the prefix that
> will be returned from "getRoutingObject".
>
> An example of doing this in gfsh is:
> create region --name=r1 --type=PARTITION
> --partition-resolver=org.apache.geode.cache.StringPrefixPartitionResolver
>
> Note that attempting to use a key that is not a String or does not contain
> a ':' will throw an exception. This is to help developers realize they made
> a mistake.
>
> Note that the delimiter is always a ':'. It would be easy to made the
> delimiter configurable when using apis or xml but currently gfsh does not
> provide a way to pass parameters to the --partition-resolver create region
> option.
>
> The only public api change this proposal makes is the new
> StringPrefixPartitionResolver class.
>

[DISCUSS] easy string based partitioning

[Darrel Schneider]

Geode partitioned regions usually partition the data based on the key's
hashcode.
You can do your own partitioning by implementing the PartitionResolver
interface and configuring it on the partitioned region.

In some use cases needing to deploy your class that implements
PartitionResolver can be problematic so we would like to find a way to
offer partitioning based on a portion of the key (instead of the default
which uses the entire key) that does not require you to implement your own
PartitionResolver and does not require you to deploy your own code to do
the custom partitioning.

Another group of users that do not want to implement PartitionResolver are
non-java clients. So the solution is required to be usable by non-java
geode clients without needing to reimplement the client to support a new
feature.

Another constraint on the solution is for it to be both easy to use and
easy to implement.

The proposed solution is to provide a class named:
org.apache.geode.cache.StringPrefixPartitionResolver
This class will implement PartitionResolver and have a default constructor.
To use it you need to configure a partitioned region's PartitionResolver
using the already existing mechanism for this (api, gfsh, or xml).
The StringPrefixPartitionResolver will require all keys on its region to be
of type String.
It also requires that the string key contains at least one ':' character.
The substring of the key that precedes the first ':' is the prefix that
will be returned from "getRoutingObject".

An example of doing this in gfsh is:
create region --name=r1 --type=PARTITION
--partition-resolver=org.apache.geode.cache.StringPrefixPartitionResolver

Note that attempting to use a key that is not a String or does not contain
a ':' will throw an exception. This is to help developers realize they made
a mistake.

Note that the delimiter is always a ':'. It would be easy to made the
delimiter configurable when using apis or xml but currently gfsh does not
provide a way to pass parameters to the --partition-resolver create region
option.

The only public api change this proposal makes is the new
StringPrefixPartitionResolver class.

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #573 was successful.
---
Scheduled
1870 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

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

[Patrick Rhomberg]

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




geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
Line 71 (original)


We could use an `authorize(Resource r, Operation o, Target t)` that infers 
`key = "*"`


- Patrick Rhomberg


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 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/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller resolved GEODE-2947.

Resolution: Fixed

Documentation update cherry picked to the release/1.2.0 branch with 
https://github.com/apache/geode/commit/96f77fc8c9b4e76e7f88d7561bd4f31c98198ac2

> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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&focusedCommentId=16035527#comment-16035527
 ] 

ASF subversion and git services commented on GEODE-2947:


Commit 96f77fc8c9b4e76e7f88d7561bd4f31c98198ac2 in geode's branch 
refs/heads/release/1.2.0 from [~karensmolermiller]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=96f77fc ]

GEODE-2947: Document revised gfsh destroy error message

This closes #555


> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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 GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

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


> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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)

[GitHub] geode pull request #555: GEODE-2947: Document revised gfsh destroy error mes...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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&focusedCommentId=16035524#comment-16035524
 ] 

ASF subversion and git services commented on GEODE-2947:


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

GEODE-2947: Document revised gfsh destroy error message

This closes #555


> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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-2661) CacheListener gets invoked when an non-existent entry is removed using removeAll

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2661:


Commit 39bfdccf82ccd86de99f722076d05ad542e468fc in geode's branch 
refs/heads/release/1.2.0 from [~lgallinat]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=39bfdcc ]

GEODE-2661: afterDestroy events fired on non-existent keys during destroy or 
removeAll.

In a client/server topology, afterDestroy events were fired on keys that did 
not exist
for removeAll, remove and destroy. This suppresses those events.

cherry-pick 08451526ea5a87e15c4ce609bdf5a0f14fed7d06 from develop


> 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
>
>
> PROBLEM: CacheListener.afterDestroy is invoked for an entry which does not 
> exist.
> FIX: Make entry is not a re-destroyed entry.
> 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] [Assigned] (GEODE-2931) Document existing REST API functionality for primitives as PUT values

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller reassigned GEODE-2931:
--

Assignee: (was: Karen Smoler Miller)

> Document existing REST API functionality for primitives as PUT values
> -
>
> Key: GEODE-2931
> URL: https://issues.apache.org/jira/browse/GEODE-2931
> Project: Geode
>  Issue Type: Sub-task
>  Components: docs
>Reporter: Joey McAllister
>
> Plain text is valid JSON, but is not supported by the REST API. Same issue 
> for all primitive types: bool, number, arrays. Only objects are accepted.
> This is a pain point with a story (GEODE-2794) to address it, but the current 
> functionality/limitations should be noted in the documentation.



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

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

[Jinmei Liao]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > 
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.
> 
> Jinmei Liao wrote:
> I tried to do this, but it's more involved than just adding the 
> repeatable annoation here. The user of these annotations will need to be 
> updated to handle multiple values. Possibly for future enhancement.
> 
> Patrick Rhomberg wrote:
> Here's a diff on my branch that I think does what we want.
> 
> 
> https://github.com/PurelyApplied/geode/commit/e82688ffb08e4b4542d2f440cb62d46d2b7bcf3c
> 
> Am I missing a use case where 
> `method.getAnnotation(ResourceOperation.class)` is going to be used by some 
> user's custom implementations?  Because otherwise we only need to change the 
> annotation processing in `CommandProcessor::executeCommand`, as far as I can 
> tell.

this works for annotations we added on commands. This annotation is also used 
on MXBeans, e.g. MemberMXBean, the place where it's parsing that info is in 
MBeanServerWrapper.getOperationContext(), that's where it's give us hickups.


- Jinmei


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


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 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/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Patrick Rhomberg]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > 
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.
> 
> Jinmei Liao wrote:
> I tried to do this, but it's more involved than just adding the 
> repeatable annoation here. The user of these annotations will need to be 
> updated to handle multiple values. Possibly for future enhancement.

Here's a diff on my branch that I think does what we want.

https://github.com/PurelyApplied/geode/commit/e82688ffb08e4b4542d2f440cb62d46d2b7bcf3c

Am I missing a use case where `method.getAnnotation(ResourceOperation.class)` 
is going to be used by some user's custom implementations?  Because otherwise 
we only need to change the annotation processing in 
`CommandProcessor::executeCommand`, as far as I can tell.


- Patrick


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


On June 2, 2017, 4:08 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 4:08 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/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
>  c2c6e1425 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/6/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

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

[Swapnil Bawaskar]

I don't see how this RoutableKey approach, which is a Java interface will
work from non-java clients. So, in the interest of cross-language support
and keeping the usage simple, I think we should just restrict this to work
with utf-8 encoded strings with a delimiter.

I agree however that this should just be an implementation of the
PartitionResolver and should be configured as such. i.e. while creating the
region users could say:
gfsh>create region --name=foo --type=PARTITION
--partition-resolver=org.apache.geode.StringPartitionResolver
which will just use a default delimiter (say ":"). In the future we can try
to figure out how to pass parameters to the partition resolver to make the
delimiter configurable. And may be also provide the RoutableKey for java
clients.


On Fri, Jun 2, 2017 at 10:54 AM Michael Stolz  wrote:

> +1 to the RoutableKey. Does need to be supported on any non-java clients
> too though.
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: +1-631-835-4771 <(631)%20835-4771>
>
> On Thu, Jun 1, 2017 at 8:31 PM, Darrel Schneider 
> wrote:
>
> > +1 to the RoutableKey idea.
> > It also gets rid of any need for a delimiter since the two args passed
> when
> > constructing this key define which part is for resolving routing and
> which
> > part is the key.
> >
> > As far as memory overhead goes we could do some optimization of how this
> > key is stored by not exposing the actual class we use to implement
> > RoutableKey but instead RoutableKey would just be an interface and we
> would
> > provide a factory method on Cache for creating a new key.
> >
> >
> > On Thu, Jun 1, 2017 at 4:59 PM, Fred Krone  wrote:
> >
> > > Going this route we could do something like: RoutableKey
> implements
> > > PartitionResolver and pass it in as a key (this was batted around in
> the
> > > feature narrative).
> > >
> > > Here RO is the routing object, K is the original key.
> > >
> > > Region.put already looks for key to implement PartitonResolver and if
> it
> > > does will use the routing object.
> > >
> > > This way we don't need any API changes, you don't even need to set this
> > > PartitionResolver on gfsh create region and if we do this with generics
> > you
> > > can make whatever compound key you like.
> > >
> > > Basically we're just doing the implementation and making it generic.
> One
> > > caveat is that this neglects .Net clients and will use more memory
> > > overhead.
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Jun 1, 2017 at 2:20 PM, Michael Stolz 
> wrote:
> > >
> > > > I think that implementing a pre-built PartitionResolver that is
> bundled
> > > > with Geode would enable users to leverage that PartitionResolver
> > without
> > > > writing any code just by mentioning its class name during region
> > > creation.
> > > >
> > > > That's a huge win. Co-location without writing code. Period. Yay!
> > > >
> > > > Adding the ability to specify the delimiter is a nice add-on to that
> > and
> > > > could probably be done by parameterizing the PartitionResolver much
> > like
> > > > the way Listeners can be parameterized but its not there in the
> tooling
> > > at
> > > > this moment.
> > > >
> > > > What's bothering me is the fact that we already have a way to
> specify a
> > > > PartitionResolver generically built into all our tooling, and now we
> > are
> > > > adding another way to specify this particular PartitionResolver that
> > > could
> > > > cause confusion with the current generic way, and could even run into
> > > > conflicts that we need no handle specially.
> > > >
> > > > If we have already taken care of ensuring that the class is on the
> > > > classpath, it is probably not really much easier to say
> > > > partition-by-prefix=true
> > > > than it is to say
> > > > partition-resolver=org.apache.geode.somepackage.some.class
> > > > and if we don't add "partition-by-prefix" into the API and tooling
> then
> > > > there's no temptation to ever say both.
> > > >
> > > >
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer, GemFire Product Manager
> > > > Mobile: +1-631-835-4771 <(631)%20835-4771>
> > > >
> > > > On Thu, Jun 1, 2017 at 4:54 PM, Darrel Schneider <
> > dschnei...@pivotal.io>
> > > > wrote:
> > > >
> > > > > We already have a general purpose mechanism that, if you are
> willing
> > to
> > > > > write java code, handles all the permutations you mention. That
> > > mechanism
> > > > > is the PartitionResolver interface.
> > > > >
> > > > > This new feature is intended to give users a way to control how
> their
> > > > keys
> > > > > are partitioned without writing any java code. I think by
> > "unnecessary
> > > > API"
> > > > > you mean "unnecessary feature". But our current features do not
> give
> > > you
> > > > a
> > > > > way to control partitioning without implementing a
> PartitionResolver.
> > > > This
> > > > > new feature allows you to just configure your region (using gfsh,
> > xml,
> > > or
> > > > > apis) and then format your s

[jira] [Created] (GEODE-3026) If a region defining lucene indexes cannot be created, it leaves an AEQ behind

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-3026:


 Summary: If a region defining lucene indexes cannot be created, it 
leaves an AEQ behind
 Key: GEODE-3026
 URL: https://issues.apache.org/jira/browse/GEODE-3026
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Barry Oglesby


This is ok if the member is started with xml, because it will fail to start, 
but if the region is attempted to be created using java API or gfsh, then the 
server will be in an inconsistent state.

It will have defined the AEQ like:
{noformat}
[info 2017/06/02 13:02:15.047 PDT   tid=0x1] Started  
ParallelGatewaySender{id=AsyncEventQueue_full_index#_data,remoteDsId=-1,isRunning
 =true}
{noformat}
But will fail to create the region (in this case I created the region with a 
different number of buckets):
{noformat}
[warning 2017/06/02 13:02:15.126 PDT   tid=0x1] Initialization failed for 
Region /data
java.lang.IllegalStateException: The total number of buckets found in 
PartitionAttributes ( 16 ) is incompatible with the total number of buckets 
used by other distributed members. Set the number of buckets to  66
at 
org.apache.geode.internal.cache.PartitionRegionConfigValidator.validatePartitionAttrsFromPRConfig(PartitionRegionConfigValidator.java:102)
at 
org.apache.geode.internal.cache.PartitionedRegion.registerPartitionedRegion(PartitionedRegion.java:1337)
at 
org.apache.geode.internal.cache.PartitionedRegion.initPRInternals(PartitionedRegion.java:987)
at 
org.apache.geode.internal.cache.PartitionedRegion.initialize(PartitionedRegion.java:1157)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3104)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3004)
at 
org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2992)
at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:758)
at TestServer.createIndexAndRegionUsingAPI(TestServer.java:104)
at TestServer.main(TestServer.java:47)
{noformat}
So, at the end of the GemFireCacheImpl.createVMRegion call, the AEQ exists but 
the region doesn't.




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

Review Request 59757: GEODE-3024 race condition between server and restarted locator preparing membership views

[Bruce Schuchardt]

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

Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.


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


Repository: geode


Description
---

If a locator is preparing a conflicting membership view we now abandon 
preparation of a view in a cache server and pause before retrying.  This gives 
the locator time to gather information from the cache server's view (which it 
receives in acks while preparing its own view), incorporate them into a new 
view and send it out.  When the cache server installs the new view from the 
locator it will shut down its ViewCreator thread.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeave.java
 478c4e832dd18635d0d66c4b85e2e2ce6ed5ab91 
  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messages/ViewAckMessage.java
 71bd6bcbf60fbcd9e6320195c5d9a5e1cf809e8a 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
 49b09cab058e9e68c0e029b048e9c03c585b7fe5 


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


Testing
---

new unit test, precheckin, partial regression testing


Thanks,

Bruce Schuchardt

[jira] [Created] (GEODE-3025) CI failure: org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest.transactionWithLuceneQueriesShouldThrowException

[Jason Huynh (JIRA)]

Jason Huynh created GEODE-3025:
--

 Summary: CI failure: 
org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest.transactionWithLuceneQueriesShouldThrowException
 Key: GEODE-3025
 URL: https://issues.apache.org/jira/browse/GEODE-3025
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Jason Huynh


The issue is that the client can sometimes execute in a transaction if single 
hop is enabled but not if single hop is disabled. 

org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest > 
transactionWithLuceneQueriesShouldThrowException(PARTITION_WITH_CLIENT) [0] 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest$$Lambda$57/2004630790.run
 in VM 3 running on Host priapus.apache.org 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.cache.lucene.LuceneQueriesClientDUnitTest.transactionWithLuceneQueriesShouldThrowException(LuceneQueriesClientDUnitTest.java:88)

Caused by:
org.apache.geode.cache.lucene.LuceneQueryException: Lucene Query cannot 
be executed within a transaction
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findTopEntries(LuceneQueryImpl.java:124)
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:98)
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:94)
at 
org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest.lambda$transactionWithLuceneQueriesShouldThrowException$30c11d8e$1(LuceneQueriesClientDUnitTest.java:96)



--
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 GitHub Bot (JIRA)]

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

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

Github user dihardman commented on the issue:

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

On Fri, Jun 2, 2017 at 9:26 AM, Karen Miller 
wrote:

> @dihardman  @boglesby
>  @ladyVader 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/555
> Commit Summary
>
>- GEODE-2947: Document revised gfsh destroy error message
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (5)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/555.patch
>- https://github.com/apache/geode/pull/555.diff
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> , or mute the thread
> 

> .
>



> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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)

[GitHub] geode issue #555: GEODE-2947: Document revised gfsh destroy error message

[dihardman]

Github user dihardman commented on the issue:

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

On Fri, Jun 2, 2017 at 9:26 AM, Karen Miller 
wrote:

> @dihardman  @boglesby
>  @ladyVader 
> Please review.
> --
> You can view, comment on, or merge this pull request online at:
>
>   https://github.com/apache/geode/pull/555
> Commit Summary
>
>- GEODE-2947: Document revised gfsh destroy error message
>
> File Changes
>
>- *M* geode-docs/tools_modules/lucene_integration.html.md.erb
> (5)
>
> Patch Links:
>
>- https://github.com/apache/geode/pull/555.patch
>- https://github.com/apache/geode/pull/555.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.
---

Build failed in Jenkins: Geode-release #52

[Apache Jenkins Server]

See 


Changes:

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

[jiliao] GEODE-3006: reduce the frequency of ping request and reduce the 
loglevel

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

[jstewart] GEODE-2989: Improve mechanism for scanning the classpath to find gfsh

[jstewart] GEODE-2966: RefactorLauncherLifecycleCommands

[jstewart] GEODE-2966: Restore command changes lost in merge conflict

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

[eshu] GEODE-2892: Add sizeOnServer and isEmptyOnServer to Region

--
[...truncated 178.42 KB...]
:geode-json:distributedTest 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: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

org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest > 
transactionWithLuceneQueriesShouldThrowException(PARTITION_WITH_CLIENT) [0] 
FAILED
org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest$$Lambda$57/2004630790.run
 in VM 3 running on Host priapus.apache.org 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.cache.lucene.LuceneQueriesClientDUnitTest.transactionWithLuceneQueriesShouldThrowException(LuceneQueriesClientDUnitTest.java:88)

Caused by:
org.apache.geode.cache.lucene.LuceneQueryException: Lucene Query cannot 
be executed within a transaction
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findTopEntries(LuceneQueryImpl.java:124)
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:98)
at 
org.apache.geode.cache.lucene.internal.LuceneQueryImpl.findPages(LuceneQueryImpl.java:94)
at 
org.apache.geode.cache.lucene.LuceneQueriesClientDUnitTest.lambda$transactionWithLuceneQueriesShouldThrowException$30c11d8e$1(LuceneQueriesClientDUnitTest.java:96)

318 tests completed, 1 failed
:geode-lucene:distributedTest FAILED
: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:distrib

Re: Review Request 59754: GEODE-2928: get rid of the isGfshVM static variable

[Jinmei Liao]

> On June 2, 2017, 5:53 p.m., Jared Stewart wrote:
> > geode-core/src/test/java/org/apache/TestSuite.java
> > Lines 24 (patched)
> > 
> >
> > I suspect that you may not have intended to include this file in your 
> > commit.

oh, yeah, good catch.


- Jinmei


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


On June 2, 2017, 4:48 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59754/
> ---
> 
> (Updated June 2, 2017, 4:48 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidate the availability indicators
> * remove the isGfshVM and isGfshVM() method
> * enhance the MultiStepCommand to include info on shellOnly commands to 
> enhance command validation
> * remove the SUPPORT_MULTIPLE_GFSH static flag and properly remove the gfsh 
> instance at the end of each test
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/GfeConsoleReaderFactory.java
>  120d6257b 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e6dc3973 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  038e0691e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
>  e61934261 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CommandAvailabilityIndicator.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  bc9c05b81 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  ad40518f8 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  cb9c4fe50 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  30d840a0f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  6441f20cc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  9d263d110 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  2774584ff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshCommand.java
>  d46024d38 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  b3d96757b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  4c668b681 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MemberCommands.java
>  695718a82 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  9754d7d52 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  9f1290d16 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  d3c263509 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  2009dcc05 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  efd10d27b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StatusCommands.java
>  fffb9646f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  28686ce4d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  e2164a375 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
>  d53261d04 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/MultiStepCommand.java
>  6708726cd 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  fa0f3b259 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
>  f453ec67c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
>  c5ff6b6a5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.ja

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

[Michael Stolz]

+1 to the RoutableKey. Does need to be supported on any non-java clients
too though.

--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: +1-631-835-4771

On Thu, Jun 1, 2017 at 8:31 PM, Darrel Schneider 
wrote:

> +1 to the RoutableKey idea.
> It also gets rid of any need for a delimiter since the two args passed when
> constructing this key define which part is for resolving routing and which
> part is the key.
>
> As far as memory overhead goes we could do some optimization of how this
> key is stored by not exposing the actual class we use to implement
> RoutableKey but instead RoutableKey would just be an interface and we would
> provide a factory method on Cache for creating a new key.
>
>
> On Thu, Jun 1, 2017 at 4:59 PM, Fred Krone  wrote:
>
> > Going this route we could do something like: RoutableKey implements
> > PartitionResolver and pass it in as a key (this was batted around in the
> > feature narrative).
> >
> > Here RO is the routing object, K is the original key.
> >
> > Region.put already looks for key to implement PartitonResolver and if it
> > does will use the routing object.
> >
> > This way we don't need any API changes, you don't even need to set this
> > PartitionResolver on gfsh create region and if we do this with generics
> you
> > can make whatever compound key you like.
> >
> > Basically we're just doing the implementation and making it generic.  One
> > caveat is that this neglects .Net clients and will use more memory
> > overhead.
> >
> >
> >
> >
> >
> > On Thu, Jun 1, 2017 at 2:20 PM, Michael Stolz  wrote:
> >
> > > I think that implementing a pre-built PartitionResolver that is bundled
> > > with Geode would enable users to leverage that PartitionResolver
> without
> > > writing any code just by mentioning its class name during region
> > creation.
> > >
> > > That's a huge win. Co-location without writing code. Period. Yay!
> > >
> > > Adding the ability to specify the delimiter is a nice add-on to that
> and
> > > could probably be done by parameterizing the PartitionResolver much
> like
> > > the way Listeners can be parameterized but its not there in the tooling
> > at
> > > this moment.
> > >
> > > What's bothering me is the fact that we already have a way to specify a
> > > PartitionResolver generically built into all our tooling, and now we
> are
> > > adding another way to specify this particular PartitionResolver that
> > could
> > > cause confusion with the current generic way, and could even run into
> > > conflicts that we need no handle specially.
> > >
> > > If we have already taken care of ensuring that the class is on the
> > > classpath, it is probably not really much easier to say
> > > partition-by-prefix=true
> > > than it is to say
> > > partition-resolver=org.apache.geode.somepackage.some.class
> > > and if we don't add "partition-by-prefix" into the API and tooling then
> > > there's no temptation to ever say both.
> > >
> > >
> > >
> > > --
> > > Mike Stolz
> > > Principal Engineer, GemFire Product Manager
> > > Mobile: +1-631-835-4771
> > >
> > > On Thu, Jun 1, 2017 at 4:54 PM, Darrel Schneider <
> dschnei...@pivotal.io>
> > > wrote:
> > >
> > > > We already have a general purpose mechanism that, if you are willing
> to
> > > > write java code, handles all the permutations you mention. That
> > mechanism
> > > > is the PartitionResolver interface.
> > > >
> > > > This new feature is intended to give users a way to control how their
> > > keys
> > > > are partitioned without writing any java code. I think by
> "unnecessary
> > > API"
> > > > you mean "unnecessary feature". But our current features do not give
> > you
> > > a
> > > > way to control partitioning without implementing a PartitionResolver.
> > > This
> > > > new feature allows you to just configure your region (using gfsh,
> xml,
> > or
> > > > apis) and then format your string keys to control the partitioning.
> No
> > > need
> > > > to implement a PartitionResolver. I think that is the requirement for
> > > this
> > > > feature. Are you arguing that this requirement does not have enough
> > value
> > > > for our customers to justify adding product feature for it? Or do you
> > > think
> > > > this requirement should be met with a different solution?
> > > >
> > > > On Thu, Jun 1, 2017 at 11:59 AM, Michael Stolz 
> > > wrote:
> > > >
> > > > > I really think that we're going down the wrong road with this
> > > hard-coded
> > > > > partition-by-prefix thing.
> > > > >
> > > > > I expect that we will have several different flavors of pre-built
> > > > compound
> > > > > key classes.
> > > > > We will probably have one that takes two Integers, quite possibly
> one
> > > > with
> > > > > an Integer and a String.
> > > > > There could be an untold number of permutations all of which are
> > > handled
> > > > by
> > > > > the current way of specifying the classname.
> > > > > It also eliminates the possibility of having both
> "partitionByPrefix"
> > > > and a
> > > > > "Partit

Re: Review Request 59754: GEODE-2928: get rid of the isGfshVM static variable

[Jared Stewart]

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




geode-core/src/test/java/org/apache/TestSuite.java
Lines 24 (patched)


I suspect that you may not have intended to include this file in your 
commit.


- Jared Stewart


On June 2, 2017, 4:48 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59754/
> ---
> 
> (Updated June 2, 2017, 4:48 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jared Stewart, Ken Howe, Kirk Lund, and 
> Patrick Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * consolidate the availability indicators
> * remove the isGfshVM and isGfshVM() method
> * enhance the MultiStepCommand to include info on shellOnly commands to 
> enhance command validation
> * remove the SUPPORT_MULTIPLE_GFSH static flag and properly remove the gfsh 
> instance at the end of each test
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/GfeConsoleReaderFactory.java
>  120d6257b 
>   geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
> 2e6dc3973 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java
>  038e0691e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
>  e61934261 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CommandAvailabilityIndicator.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
>  bc9c05b81 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
>  ad40518f8 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
>  cb9c4fe50 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
>  30d840a0f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
>  6441f20cc 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
>  9d263d110 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
>  2774584ff 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshCommand.java
>  d46024d38 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
>  b3d96757b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  4c668b681 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MemberCommands.java
>  695718a82 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
>  9754d7d52 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
>  9f1290d16 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
>  d3c263509 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
>  2009dcc05 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
>  efd10d27b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StatusCommands.java
>  fffb9646f 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
>  28686ce4d 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
>  e2164a375 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
>  d53261d04 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/MultiStepCommand.java
>  6708726cd 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
>  fa0f3b259 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
>  f453ec67c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
>  c5ff6b6a5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
>  2b39bedd1 
>   geode-core/src/test/java/org/apache/TestSuite.java PRE-CREATION 
>   
> geode-core/src/test/

Jenkins build is back to normal : Geode-nightly-flaky #24

[Apache Jenkins Server]

See 

Re: Review Request 59736: GEODE-2933: jmx-manager-hostname-for-clients should be a gfsh option

[Patrick Rhomberg]

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



1) `¯_(?)_/¯`
2) I think the setting of defaults would belong to the CommandArguments 
builder.  I think it would read nicely for that to be wrapped in a `try` with 
the error returns in lines 225 and 235 as caught exceptions.
3) I think this overlap could be resolved cleanly with a 
`LocatorLauncher.Builder.buildFromArgs(argsObject)` method.  We already have a 
`*.parseArguments`, which could be removed/depricated to help cleanly define 
that line if we want.
4) I like the `(method, args)` as a paradigm, but I don't know how extensive an 
effort would be needed to standardize this across the codebase.

- Patrick Rhomberg


On June 1, 2017, 11:10 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59736/
> ---
> 
> (Updated June 1, 2017, 11:10 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> I'm having trouble finding a way to test the actual product changes for 
> GEODE-2933 that doesn't feel hacky.  I don't intend to commit this review 
> request in the current state. Rather, I wanted to start a discussion to 
> validate the general strategy and consider alternative suggestions before I 
> get too far into the work.
> 
> There is a StartLocatorCommandArguments class introduced that makes easier 
> passing around all of the arguments to startLocator(). It also allows setting 
> one or two arguments for tests without needing to put the other 20 nulls in 
> the correct positions.  Thoughts/questions I still have:
> 
> 1) Does the improved testability justify the added boilerplate of 
> StartLocatorCommandArguments?
> 2) Should the setting of "default values" (lines ~221-246 in 
> LauncherLifecycleCommands) also be moved into this class?
> 3) It seems like there some overlap between the intent of 
> StartLocatorCommandArguments and LocatorLauncher.Builder - not sure where the 
> boundary between these two should be.
> 4) There are more places that `args` could replace telescoped methods.  E.g. 
> `createStartLocatorCommandLine` could take in `(locatorLauncher, args)` 
> rather than ```(locatorLauncher,
>  gemfirePropertiesPathname, gemfireSecurityPropertiesPathname, 
> gemfireProperties,
>   classpath, includeSystemClasspath, jvmArgsOpts, initialHeap, 
> maxHeap)```
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  4c668b6813de71aae9e3e46c82a5c231a41c1f6a 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartLocatorCommandArguments.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  9f68d3a5eaadbe8f1bd95ec8df85ed1f65aa67ce 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartLocatorCommandArgumentsTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59736/diff/1/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

[jira] [Commented] (GEODE-2444) Making Redis Adapter easier to use and more robust

[ASF GitHub Bot (JIRA)]

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

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

Github user kohlmu-pivotal commented on the issue:

https://github.com/apache/geode/pull/404
  
@yhilem @ggreen @bbaynes, there is currently a feature branch 
https://github.com/apache/geode/tree/feature/GEODE-2444, which started 
splitting the Redis Adapter into its own module.
I would prefer this splitting of the Redis adapter into its own module to 
be part of the integration.


> Making Redis Adapter easier to use and more robust
> --
>
> Key: GEODE-2444
> URL: https://issues.apache.org/jira/browse/GEODE-2444
> Project: Geode
>  Issue Type: Wish
>  Components: redis
>Reporter: Addison
>
> The goal of this effort is to further test and complete the Redis Adapter to 
> make the code more readable and performant. 



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

[GitHub] geode issue #404: Geode 2469

[kohlmu-pivotal]

Github user kohlmu-pivotal commented on the issue:

https://github.com/apache/geode/pull/404
  
@yhilem @ggreen @bbaynes, there is currently a feature branch 
https://github.com/apache/geode/tree/feature/GEODE-2444, which started 
splitting the Redis Adapter into its own module.
I would prefer this splitting of the Redis adapter into its own module to 
be part of the integration.


---
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-2981) Fix the line feed code of the test expected value

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/530
  
Thank you for your contribution, looks good to me!


> Fix the line feed code of the test expected value
> -
>
> Key: GEODE-2981
> URL: https://issues.apache.org/jira/browse/GEODE-2981
> Project: Geode
>  Issue Type: Test
>  Components: management, tests
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> I mainly use the Windows. When I run the test on Windows, because Assertion 
> fails due to the difference in line feed code, I want to change this so that 
> it does not depend on the runtime environment.
> The target classes are as follows:
> - org.apache.geode.management.internal.cli.shell.GfshJunitTest
> - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest
> - org.apache.geode.management.internal.cli.help.HelperUnitTest



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

[GitHub] geode issue #530: GEODE-2981: Fix the line feed code of the test expected va...

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/530
  
Thank you for your contribution, looks good to me!


---
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-2981) Fix the line feed code of the test expected value

[ASF GitHub Bot (JIRA)]

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

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

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/530
  
will pull this in after testing


> Fix the line feed code of the test expected value
> -
>
> Key: GEODE-2981
> URL: https://issues.apache.org/jira/browse/GEODE-2981
> Project: Geode
>  Issue Type: Test
>  Components: management, tests
>Reporter: Masaki Yamakawa
>Priority: Minor
>
> I mainly use the Windows. When I run the test on Windows, because Assertion 
> fails due to the difference in line feed code, I want to change this so that 
> it does not depend on the runtime environment.
> The target classes are as follows:
> - org.apache.geode.management.internal.cli.shell.GfshJunitTest
> - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest
> - org.apache.geode.management.internal.cli.help.HelperUnitTest



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

[GitHub] geode issue #530: GEODE-2981: Fix the line feed code of the test expected va...

[jinmeiliao]

Github user jinmeiliao commented on the issue:

https://github.com/apache/geode/pull/530
  
will pull this in after testing


---
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 59754: GEODE-2928: get rid of the isGfshVM static variable

[Jinmei Liao]

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

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


Repository: geode


Description
---

* consolidate the availability indicators
* remove the isGfshVM and isGfshVM() method
* enhance the MultiStepCommand to include info on shellOnly commands to enhance 
command validation
* remove the SUPPORT_MULTIPLE_GFSH static flag and properly remove the gfsh 
instance at the end of each test


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/GfeConsoleReaderFactory.java 
120d6257b 
  geode-core/src/main/java/org/apache/geode/management/cli/CliMetaData.java 
2e6dc3973 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/CliUtil.java 
038e0691e 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ClientCommands.java
 e61934261 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CommandAvailabilityIndicator.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ConfigCommands.java
 bc9c05b81 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateAlterDestroyRegionCommands.java
 ad40518f8 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DataCommands.java
 cb9c4fe50 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DeployCommands.java
 30d840a0f 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda84 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DurableClientCommands.java
 6441f20cc 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportImportClusterConfigurationCommands.java
 9d263d110 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/FunctionCommands.java
 2774584ff 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/GfshCommand.java
 d46024d38 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/IndexCommands.java
 b3d96757b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 4c668b681 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MemberCommands.java
 695718a82 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/MiscellaneousCommands.java
 9754d7d52 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/PDXCommands.java
 9f1290d16 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/QueueCommands.java
 d3c263509 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/RegionCommands.java
 2009dcc05 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ShellCommands.java
 efd10d27b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/StatusCommands.java
 fffb9646f 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/WanCommands.java
 28686ce4d 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/DataCommandFunction.java
 e2164a375 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
 d53261d04 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/multistep/MultiStepCommand.java
 6708726cd 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
 fa0f3b259 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/result/AbstractResultData.java
 f453ec67c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/Gfsh.java
 c5ff6b6a5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
 2b39bedd1 
  geode-core/src/test/java/org/apache/TestSuite.java PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/DataCommandMBeanTest.java 
PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/HeadlessGfsh.java
 9ea22dac0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/CliCommandTestBase.java
 b582e529c 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/MemberCommandsDUnitTest.java
 5bbfc5b3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ShowDeadlockDUnitTest.java
 e7ae38e43 
  
geode-core/src/test/java/org/apache/geode/test/dunit/rules/GfshShellConnectionRule.java
 bc709db56 
  
geode-lucene/src/main/java/org/apache/geode/cache/lucene/internal/cli/LuceneIndexCommands.java
 da0dfa23c 


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


Test

[jira] [Commented] (GEODE-2935) Add Events link to Geode site footer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2935:


Commit c7f953ae870655073dac4aa68a817d369bf5e8c7 in geode-site's branch 
refs/heads/asf-site from [~amb]
[ https://git-wip-us.apache.org/repos/asf?p=geode-site.git;h=c7f953a ]

GEODE-2935 Add Events link to footer, events img to Community


> Add Events link to Geode site footer
> 
>
> Key: GEODE-2935
> URL: https://issues.apache.org/jira/browse/GEODE-2935
> Project: Geode
>  Issue Type: Task
>  Components: web-content
>Reporter: Joey McAllister
>Assignee: Joey McAllister
>Priority: Minor
>  Labels: website
>
> From [~mbretl]:
> {quote}
> ASF has created a new tool for scanning TLP sites for compliance and other
> requests. The new tool is located at https://whimsy.apache.org/site, with our 
> own Geode report at https://whimsy.apache.org/site/project/geode. The report 
> looks good, with only one missing requirement of an Events page.
> When I searched for 'event' on the [source of the 
> tool|https://gitbox.apache.org/repos/asf?p=whimsy.git;a=blob_plain;f=tools/site-scan.rb;hb=HEAD],
>  I found http://www.apache.org/events/README.txt, with more event information.
> However, looking at the code, it is searching for: 'apache.org/events/'. So
> we can either create the link as text or use the image as a link.
> {quote}



--
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 GitHub Bot (JIRA)]

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

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

GitHub user karensmolermiller opened a pull request:

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

GEODE-2947: Document revised gfsh destroy error message

@dihardman @boglesby @ladyVader Please review.


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

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

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

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






> 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: docs, lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Karen Smoler Miller
> 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)

[GitHub] geode pull request #555: GEODE-2947: Document revised gfsh destroy error mes...

[karensmolermiller]

GitHub user karensmolermiller opened a pull request:

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

GEODE-2947: Document revised gfsh destroy error message

@dihardman @boglesby @ladyVader Please review.


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

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

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

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






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

[GitHub] geode issue #404: Geode 2469

[bbaynes]

Github user bbaynes commented on the issue:

https://github.com/apache/geode/pull/404
  
@yhilem @ggreen  Looks like a great use case.  The PR may need a little 
cleanup (based on Galen's comments), but it would be good to get this in.  



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

[Jinmei Liao]

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

(Updated June 2, 2017, 4:08 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 (updated)
-

  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de56 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cf 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda84 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e5 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da46441 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271e 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d19 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b0 


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

Changes: https://reviews.apache.org/r/59692/diff/5-6/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

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

[Emily Yeh]

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


Ship it!




Ship It!

- Emily Yeh


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

[GitHub] geode-site pull request #3: GEODE-2935: Add Events link to footer, events im...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/geode-site/pull/3


---
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-2935) Add Events link to Geode site footer

[ASF GitHub Bot (JIRA)]

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

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

Github user asfgit closed the pull request at:

https://github.com/apache/geode-site/pull/3


> Add Events link to Geode site footer
> 
>
> Key: GEODE-2935
> URL: https://issues.apache.org/jira/browse/GEODE-2935
> Project: Geode
>  Issue Type: Task
>  Components: web-content
>Reporter: Joey McAllister
>Assignee: Joey McAllister
>Priority: Minor
>  Labels: website
>
> From [~mbretl]:
> {quote}
> ASF has created a new tool for scanning TLP sites for compliance and other
> requests. The new tool is located at https://whimsy.apache.org/site, with our 
> own Geode report at https://whimsy.apache.org/site/project/geode. The report 
> looks good, with only one missing requirement of an Events page.
> When I searched for 'event' on the [source of the 
> tool|https://gitbox.apache.org/repos/asf?p=whimsy.git;a=blob_plain;f=tools/site-scan.rb;hb=HEAD],
>  I found http://www.apache.org/events/README.txt, with more event information.
> However, looking at the code, it is searching for: 'apache.org/events/'. So
> we can either create the link as text or use the image as a link.
> {quote}



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

[jira] [Created] (GEODE-3024) race condition between server and restarted locator preparing membership views

[Bruce Schuchardt (JIRA)]

Bruce Schuchardt created GEODE-3024:
---

 Summary: race condition between server and restarted locator 
preparing membership views
 Key: GEODE-3024
 URL: https://issues.apache.org/jira/browse/GEODE-3024
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Bruce Schuchardt


When a locator is restarted & recovers from disk it will try to take over the 
role of membership coordinator for the cluster if it finds the current 
coordinator is a cache server.  If the cache server is in the process of 
sending out a new view it may get into a race with the locator in sending out 
view preparation messages.

The locator will send out a view-prep message and the server will also send 
one.  Responses to the view-prep message will include the conflicting view and 
each of the two processes will create a new view and send it out.  This repeats 
ad-infinitum.

This problem was observed in a system that was shutting down at the same time a 
locator was being restarted.



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

Build failed in Jenkins: Geode-nightly #854

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-3006: reduce the frequency of ping request and reduce the 
loglevel

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

[jstewart] GEODE-2989: Improve mechanism for scanning the classpath to find gfsh

[jstewart] GEODE-2966: RefactorLauncherLifecycleCommands

[jstewart] GEODE-2966: Restore command changes lost in merge conflict

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

[eshu] GEODE-2892: Add sizeOnServer and isEmptyOnServer to Region

[klund] GEODE-3018: add FlakyTest category to flickering test

[lgallinat] GEODE-2661: afterDestroy events fired on non-existent keys during

--
[...truncated 95.16 KB...]
:geode-core:checkMissedTests
:geode-core:spotlessJavaCheck
:geode-core:spotlessCheck
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq: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: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:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene: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:integrationTest
:geode-old-versions:javadoc UP-TO-DATE
:geode-old-versions:javadocJar
:geode-old-versions:sourcesJar
:geode-old-versions:signArchives SKIPPED
:geode-old-versions:assemble
:geode-old-versions:compileTestJava UP-TO-DATE
:geode-old-versions:processTestResources UP-TO-DATE
:geode-old-versions:testClasses UP-TO-DATE
:geode-old-versions:checkMissedTests UP-TO-DATE
:geode-old-versions:spotlessJavaCheck
:geode-old-versions:spotlessCheck
:geode-old-versions:test UP-TO-DATE
:geode-old-versions:check
:geode-old-versions:build
:geode-old-versions:distributedTest UP-TO-DATE
:geode-old-versions:integrationTest UP-TO-DATE
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

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

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

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-reb

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

[Jinmei Liao]

> On June 1, 2017, 9:47 p.m., Patrick Rhomberg wrote:
> > geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
> > Line 29 (original), 30 (patched)
> > 
> >
> > Is it possible to make this `@Repeatable`?  There are some operations 
> > that require multiple security permissions, and it would be nice to be able 
> > to just annotate those functions twice.
> > 
> > For instance, `DistributedSystemMXBean.backupAllMembers` should have 
> > `DATA:READ` and `CLUSTER:WRITE:DISK`.

I tried to do this, but it's more involved than just adding the repeatable 
annoation here. The user of these annotations will need to be updated to handle 
multiple values. Possibly for future enhancement.


- Jinmei


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


On June 2, 2017, 2:31 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59692/
> ---
> 
> (Updated June 2, 2017, 2:31 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/examples/security/ExampleSecurityManager.java
>  84f97de56 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
>  f9fade1cf 
>   
> geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
>  14784c391 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
>  64fafda84 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
>  6514a33e5 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
>  fe79efbed 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
>  db3a1872a 
>   geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
> 45da46441 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
>  b728b271e 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
>  3f8f4d9d4 
>   
> geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
>  2d6fbcaeb 
>   geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
> 6080b5de8 
>   
> geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt
>  9cff80d19 
>   
> geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
>  80ff719b0 
> 
> 
> Diff: https://reviews.apache.org/r/59692/diff/5/
> 
> 
> Testing
> ---
> 
> precheckin runing
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: 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/
---

(Updated June 2, 2017, 2:31 p.m.)


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


Changes
---

review changes


Repository: geode


Description
---

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


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/examples/security/ExampleSecurityManager.java
 84f97de56 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cf 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda84 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e5 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da46441 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271e 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d19 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b0 


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

Changes: https://reviews.apache.org/r/59692/diff/4-5/


Testing
---

precheckin runing


Thanks,

Jinmei Liao

[jira] [Created] (GEODE-3023) TcpServer thread can be blocked in processRequest

[Vahram Aharonyan (JIRA)]

Vahram Aharonyan created GEODE-3023:
---

 Summary: TcpServer thread can be blocked in processRequest
 Key: GEODE-3023
 URL: https://issues.apache.org/jira/browse/GEODE-3023
 Project: Geode
  Issue Type: Bug
  Components: client/server
Reporter: Vahram Aharonyan
 Fix For: 1.2.0


TCP Server's main thread can be blocked in SSL handshake if client is not 
responsive. Socket timeout should be set before trying to configure Server's 
SSL Socket. This will allow server to close the connection if SSL handshake 
hasn't succeeded during some specified time.



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

[jira] [Created] (GEODE-3022) [JGRP00001] configuration error: the following properties in org.apache.geode.distributed.internal.membership.gms.messenger.Transport are not recognized: {ignore_dont_bun

[Sumitra Chatterjee (JIRA)]

Sumitra Chatterjee created GEODE-3022:
-

 Summary: [JGRP1] configuration error: the following properties 
in org.apache.geode.distributed.internal.membership.gms.messenger.Transport are 
not recognized: {ignore_dont_bundle=false}
 Key: GEODE-3022
 URL: https://issues.apache.org/jira/browse/GEODE-3022
 Project: Geode
  Issue Type: Bug
  Components: configuration
Reporter: Sumitra Chatterjee


Getting above exception when trying to start cache server. Further checked in 
JGroupsMessenger.java and found below:
void setMessageFlags(DistributionMessage gfmsg, Message msg) {
// Bundling is mostly only useful if we're doing no-ack work,
// which is fairly rare
msg.setFlag(Flag.DONT_BUNDLE);

As per https://issues.jboss.org/browse/JGRP-1737, DONT_BUNDLE is probably not 
to be used (correct me if I am misunderstanding). Any ideas how to get the 
server start up would be very helpful.

Thanks



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