[GitHub] geode pull request #557: add GfshParserRule to facilitate command unit test

[jinmeiliao]

GitHub user jinmeiliao opened a pull request:

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

add GfshParserRule to facilitate command unit test

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

$ git pull https://github.com/jinmeiliao/geode gfshParserRule

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

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


commit 7e66a6eae6ede08280711d0112f6c5afae198d1d
Author: Jinmei Liao 
Date:   2017-06-05T06:51:42Z

add GfshParserRule to fascilidate command unit test




---
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 59736: GEODE-2933: jmx-manager-hostname-for-clients should be a gfsh option

[Jinmei Liao]

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



It does seem lots of added boilerplate code. And we need to repeat that for 
start server as well unless we put the common code in a parent class. the 
complexity seems to be big. 

To unit test a single command without having to pass in all these null values, 
I think we might be able to use GfshParseResult to do this. I cooked up a 
GfshParserRule in this PR: https://github.com/apache/geode/pull/557. Perhaps 
you can see if you can use it. See LauncherLifeCycleCommandTest for example.

- Jinmei Liao


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

Geode versions

[Roi Apelker]

Hello,

Where can I find information on up-coming GEODE versions, release dates etc.?
The last released version I know if is 1.1.1,

There is already a reference for 1.2 in the release notes here:
https://cwiki.apache.org/confluence/display/GEODE/Release+Notes

Also, reference for 1.3 here:
https://issues.apache.org/jira/browse/GEODE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel


But no dates... :(

Anyone knows?

Thanks,
Roi

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

GEODE and GEODE-native compatibility

[Roi Apelker]

Hi,

I am using both the GEODE and GEODE native libraries, and since the native 
library has no numbered version I am wondering if there are any compatibility 
issues.

Will the native library work with versions 1.0.0 and 1.1.1 seamlessly?

Thanks,

Roi

This message and the information contained herein is proprietary and 
confidential and subject to the Amdocs policy statement,

you may review at https://www.amdocs.com/about/email-disclaimer 

Re: GEODE and GEODE-native compatibility

[Jacob Barrett]

You asked the same question on the user list on 5/21. In case you didn't get my 
reply I'll send the same answer.

There have been no official Geode release of Geode Native but the current 
development branch is known to work with Geode server 1.0 and 1.1.

-Jake


Sent from my iPhone

> On Jun 5, 2017, at 2:49 AM, Roi Apelker  wrote:
> 
> Hi,
> 
> I am using both the GEODE and GEODE native libraries, and since the native 
> library has no numbered version I am wondering if there are any compatibility 
> issues.
> 
> Will the native library work with versions 1.0.0 and 1.1.1 seamlessly?
> 
> Thanks,
> 
> Roi
> 
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> 
> you may review at https://www.amdocs.com/about/email-disclaimer 
> 

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

[Sumitra Chatterjee (JIRA)]

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

Sumitra Chatterjee commented on GEODE-3022:
---

Can someone please take a look and suggest to move forward?

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

[jira] [Updated] (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)]

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

Sumitra Chatterjee updated GEODE-3022:
--
Priority: Blocker  (was: Major)

> [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
>Priority: Blocker
>
> 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)

[jira] [Updated] (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)]

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

Sumitra Chatterjee updated GEODE-3022:
--
Component/s: (was: configuration)

> [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
>Reporter: Sumitra Chatterjee
>Priority: Blocker
>
> 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)

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

[Michael Stolz]

The actual key should be the whole string. Not just that after the colon.

--
Mike Stolz
Principal Engineer - Gemfire Product Manager
Mobile: 631-835-4771 <(631)%20835-4771>

On Jun 2, 2017 8:34 PM, "Fred Krone (JIRA)"  wrote:

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

[jira] [Commented] (GEODE-2981) Fix the line feed code of the test expected value

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2981:


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

GEODE-2981: Fix the line feed code of the test expected value

* Fixed the line feed code of the test expectation value so that it does
not depend on the runtime environment.
* this closes #530


> 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 pull request #530: GEODE-2981: Fix the line feed code of the test expe...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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=16037069#comment-16037069
 ] 

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

Github user asfgit closed the pull request at:

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


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

Re: [DISCUSS] easy string based partitioning

[Udo Kohlmeyer]

Whilst I like the idea to make something (and yes, 
DelimitedStringPartitionResolver is the simplest), I feel that we might 
be able to do one better.


*/Could/* one possibly have an /*SPEL*/ 
-based 
PartitionResolver for this? At least this way, we don't have to rely on 
delimiters or a strong knowledge of REGEX.


IMO, this would provide the greatest bang for buck implementation.

--Udo



On 6/2/17 19:15, 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.

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

[jinmeiliao]

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

https://github.com/apache/geode/pull/548#discussion_r120134823
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -412,7 +411,7 @@ public Result compactDiskStore(
   @CliOption(key = CliStrings.COMPACT_DISK_STORE__NAME, mandatory = 
true,
   optionContext = ConverterHint.DISKSTORE,
   help = CliStrings.COMPACT_DISK_STORE__NAME__HELP) String 
diskStoreName,
-  @CliOption(key = CliStrings.COMPACT_DISK_STORE__GROUP,
+  @CliOption(key = CliStrings.GROUP,
--- End diff --

looks like this can have "groups" as synonym as well. Can you go through 
all your changes and make sure that member/group CliOption that take String[] 
as the option type needs to have synonym defined. Thanks!


---
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-2818) add alias to any command's options that involves "group", "member", "jar"

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/548#discussion_r120134823
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -412,7 +411,7 @@ public Result compactDiskStore(
   @CliOption(key = CliStrings.COMPACT_DISK_STORE__NAME, mandatory = 
true,
   optionContext = ConverterHint.DISKSTORE,
   help = CliStrings.COMPACT_DISK_STORE__NAME__HELP) String 
diskStoreName,
-  @CliOption(key = CliStrings.COMPACT_DISK_STORE__GROUP,
+  @CliOption(key = CliStrings.GROUP,
--- End diff --

looks like this can have "groups" as synonym as well. Can you go through 
all your changes and make sure that member/group CliOption that take String[] 
as the option type needs to have synonym defined. Thanks!


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



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

Build failed in Jenkins: Geode-nightly #857

[Apache Jenkins Server]

See 

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

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:che

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

[YehEmily]

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

https://github.com/apache/geode/pull/548#discussion_r120137950
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -412,7 +411,7 @@ public Result compactDiskStore(
   @CliOption(key = CliStrings.COMPACT_DISK_STORE__NAME, mandatory = 
true,
   optionContext = ConverterHint.DISKSTORE,
   help = CliStrings.COMPACT_DISK_STORE__NAME__HELP) String 
diskStoreName,
-  @CliOption(key = CliStrings.COMPACT_DISK_STORE__GROUP,
+  @CliOption(key = CliStrings.GROUP,
--- End diff --

Sure thing! I'll update the PR once this is done!


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

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

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/548#discussion_r120137950
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -412,7 +411,7 @@ public Result compactDiskStore(
   @CliOption(key = CliStrings.COMPACT_DISK_STORE__NAME, mandatory = 
true,
   optionContext = ConverterHint.DISKSTORE,
   help = CliStrings.COMPACT_DISK_STORE__NAME__HELP) String 
diskStoreName,
-  @CliOption(key = CliStrings.COMPACT_DISK_STORE__GROUP,
+  @CliOption(key = CliStrings.GROUP,
--- End diff --

Sure thing! I'll update the PR once this is done!


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



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

Re: [DISCUSS] easy string based partitioning

[Jens Deppe]

I like the idea of keeping the configuration 'conventional' and thus not
requiring any server configuration. As soon as you need to define a regex
on the server you might as well be writing PartitionResolver code.

As an aside I also think that using regexes to parse keys would also
introduce a measurable performance hit.

--Jens

On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer  wrote:

> Whilst I like the idea to make something (and yes,
> DelimitedStringPartitionResolver is the simplest), I feel that we might
> be able to do one better.
>
> */Could/* one possibly have an /*SPEL*/  -framework/docs/current/spring-framework-reference/html/expressions.html>-based
> PartitionResolver for this? At least this way, we don't have to rely on
> delimiters or a strong knowledge of REGEX.
>
> IMO, this would provide the greatest bang for buck implementation.
>
> --Udo
>
>
>
>
> On 6/2/17 19:15, 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.StringPrefixPart
>>> itionResolver
>>>
>>> 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] [Updated] (GEODE-3027) A developer can co-locate two keys on a put

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller updated GEODE-3027:
---
Component/s: docs

> 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: docs, 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)

[jira] [Assigned] (GEODE-2981) Fix the line feed code of the test expected value

[Jinmei Liao (JIRA)]

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

Jinmei Liao reassigned GEODE-2981:
--

Assignee: Jinmei Liao

> 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
>Assignee: Jinmei Liao
>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)

[jira] [Assigned] (GEODE-3007) Simplify support for custom GFSH commands

[Jared Stewart (JIRA)]

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

Jared Stewart reassigned GEODE-3007:


Assignee: Jared Stewart

> Simplify support for custom GFSH commands
> -
>
> Key: GEODE-3007
> URL: https://issues.apache.org/jira/browse/GEODE-3007
> Project: Geode
>  Issue Type: Improvement
>  Components: gfsh
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> Geode currently supports three ways to load GFSH commands: 
> 1. Scan the classpath for commands in 
> "org.apache.geode.management.internal.cli.commands”
> 2. Scan the classpath for commands in a package specified by a user via the 
> “user-command-packages” system property. 
> 3. Scan the classpath for commands registered in files inside 
> META-INF.services (e.g. 
> "geode-core/src/test/resources/META-INF/services/org.springframework.shell.core.CommandMarker”)
>  
> After the improvements made by GEODE-2989, there is no reason to require a 
> user to specify the location of their custom commands via one of these 
> mechanisms.  Instead, we should simply scan the entire classpath for any 
> classes implementing CommandMarker (regardless of whatever packages they live 
> in).  



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

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

[Dan Smith]

This CommandOverHttpDUnitTest seems to be failing pretty consistently in
jenkins. Is anyone looking into this failure?

-Dan

On Mon, Jun 5, 2017 at 8:30 AM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> --
> [...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:  job/Geode-nightly/ws/geode-old-client-support/src/test/
> java/com/gemstone/gemfire/cache/execute/FunctionExceptionTest.java> 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:  job/Geode-nightly/ws/geode-pulse/src/test/java/org/
> apache/geode/tools/pulse/tests/ui/PulseBase.java> uses or overrides a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note:  pulse/src/test/java/org/apache/geode/tools/pulse/controllers/
> PulseControllerJUnitTest.java> 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-rebalancer:compileTestJava
> :geode-rebalancer:processTestResources UP-TO-DATE
> :geode-rebalancer:testClasses
> :geode-rebalancer:checkMissedTests
> :geode-rebalancer:spotlessJavaCheck
> :geode-rebalancer:spotlessCh

Re: Geode versions

[Anthony Baker]

Hi Roi,

We have cut a release branch for 1.2.0.  Once we have fixed the remaining bugs 
we will vote on releasing.  We don’t published expected release dates but I 
expect that it won’t be too much longer.

Thanks,
Anthony

> On Jun 5, 2017, at 2:49 AM, Roi Apelker  wrote:
> 
> Hello,
> 
> Where can I find information on up-coming GEODE versions, release dates etc.?
> The last released version I know if is 1.1.1,
> 
> There is already a reference for 1.2 in the release notes here:
> https://cwiki.apache.org/confluence/display/GEODE/Release+Notes
> 
> Also, reference for 1.3 here:
> https://issues.apache.org/jira/browse/GEODE/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel
> 
> 
> But no dates... :(
> 
> Anyone knows?
> 
> Thanks,
> Roi
> 
> This message and the information contained herein is proprietary and 
> confidential and subject to the Amdocs policy statement,
> 
> you may review at https://www.amdocs.com/about/email-disclaimer 
> 

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

[Anthony Baker (JIRA)]

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

Anthony Baker commented on GEODE-3022:
--

Can you provide steps to reproduce this error?  What version are you testing?

> [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
>Reporter: Sumitra Chatterjee
>Priority: Blocker
>
> 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)

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

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-3005.
---
Resolution: Won't Fix

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



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

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

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-3016.
---
Resolution: Won't Fix

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



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

[jira] [Resolved] (GEODE-3010) Update PartitionAttributes for new PartitionByPrefix settings

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-3010.
---
Resolution: Won't Fix

> Update PartitionAttributes for new PartitionByPrefix settings
> -
>
> Key: GEODE-3010
> URL: https://issues.apache.org/jira/browse/GEODE-3010
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> Need to add the fields and gettors and settors
> Do the same on PartitionAttributesFactory



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

[jira] [Resolved] (GEODE-3008) Implement PartitionByPrefix Partition Resolver

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-3008.
---
Resolution: Won't Fix

> Implement PartitionByPrefix Partition Resolver
> --
>
> Key: GEODE-3008
> URL: https://issues.apache.org/jira/browse/GEODE-3008
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> This is the implementation of PartitionResolver



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

[jira] [Resolved] (GEODE-3009) Implement key String parser

[Fred Krone (JIRA)]

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

Fred Krone resolved GEODE-3009.
---
Resolution: Won't Fix

> Implement key String parser
> ---
>
> Key: GEODE-3009
> URL: https://issues.apache.org/jira/browse/GEODE-3009
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Fred Krone
>
> Parse the key according to the configured delimiter.
> Route the Entry correctly.



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

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

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3027:
--
Description: 
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.

Done
Implement PartitionResolver for delimited String keys.

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

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


> 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: docs, 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.
> Done
> Implement PartitionResolver for delimited String keys.
> 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)

[jira] [Commented] (GEODE-194) Geode Spark Connector does not support Spark 2.0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-194:
--

GitHub user metatype opened a pull request:

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

GEODE-194: Remove spark connector

Remove the spark connector code until it can be updated
for the current spark release. We should also integrate
the build lifecycle and consider how to extract this into
a separate reo.

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

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

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

$ git pull https://github.com/metatype/incubator-geode remove-spark

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

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


commit d95993b944d706baeb0c5e6c13a7d00754159123
Author: Anthony Baker 
Date:   2017-05-06T00:00:02Z

GEODE-194: Remove spark connector

Remove the spark connector code until it can be updated
for the current spark release. We should also integrate
the build lifecycle and consider how to extract this into
a separate reo.




> Geode Spark Connector does not support Spark 2.0
> 
>
> Key: GEODE-194
> URL: https://issues.apache.org/jira/browse/GEODE-194
> Project: Geode
>  Issue Type: Bug
>  Components: extensions
>Reporter: Jianxia Chen
>  Labels: experimental, gsoc2016
>
> The BasicIntegrationTest fails when using spark 1.4. e.g.
> [info] - GemFire OQL query with more complex UDT: Partitioned Region *** 
> FAILED ***
> [info]   org.apache.spark.SparkException: Job aborted due to stage failure: 
> Task 0 in stage 24.0 failed 1 times, most recent failure: Lost task 0.0 in 
> stage 24.0 (TID 48, localhost): scala.MatchError: 
> [info]Portfolio [id=3 status=active type=type3
> [info]AOL:Position [secId=AOL qty=978.0 mktValue=40.373], 
> [info]MSFT:Position [secId=MSFT qty=98327.0 mktValue=23.32]] 
> (of class ittest.io.pivotal.gemfire.spark.connector.Portfolio)
> [info]at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$4.apply(CatalystTypeConverters.scala:178)
> [info]at 
> org.apache.spark.sql.execution.RDDConversions$$anonfun$rowToRowRdd$1$$anonfun$apply$2.apply(ExistingRDD.scala:62)
> [info]at 
> org.apache.spark.sql.execution.RDDConversions$$anonfun$rowToRowRdd$1$$anonfun$apply$2.apply(ExistingRDD.scala:59)
> [info]at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> [info]at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> [info]at scala.collection.Iterator$class.foreach(Iterator.scala:727)
> [info]at 
> scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
> [info]at 
> scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
> [info]at 
> scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:103)
> [info]at 
> scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:47)
> [info]at 
> scala.collection.TraversableOnce$class.to(TraversableOnce.scala:273)
> [info]at scala.collection.AbstractIterator.to(Iterator.scala:1157)
> [info]at 
> scala.collection.TraversableOnce$class.toBuffer(TraversableOnce.scala:265)
> [info]at 
> scala.collection.AbstractIterator.toBuffer(Iterator.scala:1157)
> [info]at 
> scala.collection.TraversableOnce$class.toArray(TraversableOnce.scala:252)
> [info]at 
> scala.collection.AbstractIterator.toArray(Iterator.s

[GitHub] geode pull request #558: GEODE-194: Remove spark connector

[metatype]

GitHub user metatype opened a pull request:

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

GEODE-194: Remove spark connector

Remove the spark connector code until it can be updated
for the current spark release. We should also integrate
the build lifecycle and consider how to extract this into
a separate reo.

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

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

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

$ git pull https://github.com/metatype/incubator-geode remove-spark

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

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


commit d95993b944d706baeb0c5e6c13a7d00754159123
Author: Anthony Baker 
Date:   2017-05-06T00:00:02Z

GEODE-194: Remove spark connector

Remove the spark connector code until it can be updated
for the current spark release. We should also integrate
the build lifecycle and consider how to extract this into
a separate reo.




---
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: [DISCUSS] easy string based partitioning

[Barry Oglesby]

The top-level region may not have / need a delimiter. If you have a
customer region and a colocated orders region, the customer region key
could be the customerId, and the orders region key could be the
customerId:orderId. The colocation would be on the customerId. In the
customer region, it doesn't need a delimiter. Is it ok that this idea would
require one? Maybe the top-level region shouldn't require a delimiter? If
the StringPrefixPartitionResolver is using key.split(":"), the customer
region would return the entire key.


Thanks,
Barry Oglesby


On Mon, Jun 5, 2017 at 8:46 AM, Jens Deppe  wrote:

> I like the idea of keeping the configuration 'conventional' and thus not
> requiring any server configuration. As soon as you need to define a regex
> on the server you might as well be writing PartitionResolver code.
>
> As an aside I also think that using regexes to parse keys would also
> introduce a measurable performance hit.
>
> --Jens
>
> On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> wrote:
>
> > Whilst I like the idea to make something (and yes,
> > DelimitedStringPartitionResolver is the simplest), I feel that we might
> > be able to do one better.
> >
> > */Could/* one possibly have an /*SPEL*/  > -framework/docs/current/spring-framework-reference/
> html/expressions.html>-based
> > PartitionResolver for this? At least this way, we don't have to rely on
> > delimiters or a strong knowledge of REGEX.
> >
> > IMO, this would provide the greatest bang for buck implementation.
> >
> > --Udo
> >
> >
> >
> >
> > On 6/2/17 19:15, 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.StringPrefixPart
> >>> itionResolver
> >>>
> >>> 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-3029) Tomcat Install Documentation has incorrect required JARs

[David Anuta (JIRA)]

David Anuta created GEODE-3029:
--

 Summary: Tomcat Install Documentation has incorrect required JARs
 Key: GEODE-3029
 URL: https://issues.apache.org/jira/browse/GEODE-3029
 Project: Geode
  Issue Type: Bug
  Components: docs
Reporter: David Anuta
 Fix For: 1.2.0


This page 
(http://gemfire.docs.pivotal.io/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html)
 has the incorrect required JARs needed to install tomcat with geode.

Currently the list is:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar

The correct list should be:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar
commons-lang jar
shiro-core jar



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

[jira] [Created] (GEODE-3030) The possibleDuplicate boolean may not be set to true in previously processed AEQ events

[Barry Oglesby (JIRA)]

Barry Oglesby created GEODE-3030:


 Summary: The possibleDuplicate boolean may not be set to true in 
previously processed AEQ events
 Key: GEODE-3030
 URL: https://issues.apache.org/jira/browse/GEODE-3030
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Barry Oglesby


When a secondary bucket becomes primary, it sets possibleDuplicate=true for 
batchSize events in AbstractBucketRegionQueue.markEventsAsDuplicate:
{noformat}
java.lang.Exception: Stack trace
at java.lang.Thread.dumpStack(Thread.java:1329)
at 
com.gemstone.gemfire.internal.cache.AbstractBucketRegionQueue.markEventsAsDuplicate(AbstractBucketRegionQueue.java:329)
at 
com.gemstone.gemfire.internal.cache.BucketRegionQueue.beforeAcquiringPrimaryState(BucketRegionQueue.java:203)
at 
com.gemstone.gemfire.internal.cache.BucketAdvisor.acquiredPrimaryLock(BucketAdvisor.java:1257)
at 
com.gemstone.gemfire.internal.cache.BucketAdvisor.acquirePrimaryRecursivelyForColocated(BucketAdvisor.java:1397)
at 
com.gemstone.gemfire.internal.cache.BucketAdvisor$VolunteeringDelegate.doVolunteerForPrimary(BucketAdvisor.java:2695)
at 
com.gemstone.gemfire.internal.cache.BucketAdvisor$VolunteeringDelegate$1.run(BucketAdvisor.java:2575)
at 
com.gemstone.gemfire.internal.cache.BucketAdvisor$VolunteeringDelegate$2.run(BucketAdvisor.java:2908)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at 
com.gemstone.gemfire.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:692)
at 
com.gemstone.gemfire.distributed.internal.DistributionManager$6$1.run(DistributionManager.java:1029)
at java.lang.Thread.run(Thread.java:745)
{noformat}
In my test case, the batch size is 1 so possibleDuplicate is set to true for 
only 1 event in each bucket. It is not set for the remaining events in the 
bucket.

The ParallelQueueRemovalMessage is sent asynchronously from remote members so 
more than 1 batch of events could have been processed between message sends. 
So, possibleDuplicate should be set to true for more than batchSize events 
(possibly all of them).

Here is an example from my test. 

Server 1 is primary for bucket 5 and is stopped. Server 2 takes over primary 
for bucket 5.

{noformat}
Server 1

Server 1 processed 3 events from bucket 5 right before it was stopped:

TestGatewayEventListener processed 51427367-8d36-4425-aa02-e44c54774543
TestGatewayEventListener processed a1af3501-9030-460d-86cc-fe5b88bd5b0a
TestGatewayEventListener processed c1db3ec2-4dad--9ea7-11bd34e492ec

No ParallelQueueRemovalMessage was sent to the remote nodes before the member 
was stopped.

Server 2

Server 2 took over primary for bucket 5 and processed those same 3 events - one 
with possibleDuplicate=true, the others with possibleDuplicate=false. In all 
three cases a SQLIntegrityConstraintViolationException was thrown since the 
event had already been processed by the previous primary server.

TestGatewayEventListener caught EXPECTED exception 
eventKey=51427367-8d36-4425-aa02-e44c54774543; operation=CREATE; 
possibleDuplicate=true; 
exception=java.sql.SQLIntegrityConstraintViolationException: The statement was 
aborted because it would have caused a duplicate key value in a unique or 
primary key constraint or unique index identified by 'SQL170601145521130' 
defined on 'TRADES'.
TestGatewayEventListener caught UNEXPECTED exception 
eventKey=a1af3501-9030-460d-86cc-fe5b88bd5b0a; operation=CREATE; 
possibleDuplicate=false; 
exception=java.sql.SQLIntegrityConstraintViolationException: The statement was 
aborted because it would have caused a duplicate key value in a unique or 
primary key constraint or unique index identified by 'SQL170601145521130' 
defined on 'TRADES'.
TestGatewayEventListener caught UNEXPECTED exception 
eventKey=c1db3ec2-4dad--9ea7-11bd34e492ec; operation=CREATE; 
possibleDuplicate=false; 
exception=java.sql.SQLIntegrityConstraintViolationException: The statement was 
aborted because it would have caused a duplicate key value in a unique or 
primary key constraint or unique index identified by 'SQL170601145521130' 
defined on 'TRADES'.

AbstractBucketRegionQueue.markEventsAsDuplicate set possibleDuplicate=true for 
51427367-8d36-4425-aa02-e44c54774543, but not for the other events:

AbstractBucketRegionQueue.markEventsAsDuplicate marking posDup 
eventKey=51427367-8d36-4425-aa02-e44c54774543
AbstractBucketRegionQueue.markEventsAsDuplicate not marking posDup 
eventKey=a1af3501-9030-460d-86cc-fe5b88bd5b0a
AbstractBucketRegionQueue.markEventsAsDuplicate not marking posDup 
eventKey=c1db3ec2-4dad--9ea7-11bd34e492ec
{noformat}



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

[GitHub] geode issue #558: GEODE-194: Remove spark connector

[jhuynh1]

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/558
  
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-194) Geode Spark Connector does not support Spark 2.0

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-194:
--

Github user jhuynh1 commented on the issue:

https://github.com/apache/geode/pull/558
  
Looks good to me


> Geode Spark Connector does not support Spark 2.0
> 
>
> Key: GEODE-194
> URL: https://issues.apache.org/jira/browse/GEODE-194
> Project: Geode
>  Issue Type: Bug
>  Components: extensions
>Reporter: Jianxia Chen
>  Labels: experimental, gsoc2016
>
> The BasicIntegrationTest fails when using spark 1.4. e.g.
> [info] - GemFire OQL query with more complex UDT: Partitioned Region *** 
> FAILED ***
> [info]   org.apache.spark.SparkException: Job aborted due to stage failure: 
> Task 0 in stage 24.0 failed 1 times, most recent failure: Lost task 0.0 in 
> stage 24.0 (TID 48, localhost): scala.MatchError: 
> [info]Portfolio [id=3 status=active type=type3
> [info]AOL:Position [secId=AOL qty=978.0 mktValue=40.373], 
> [info]MSFT:Position [secId=MSFT qty=98327.0 mktValue=23.32]] 
> (of class ittest.io.pivotal.gemfire.spark.connector.Portfolio)
> [info]at 
> org.apache.spark.sql.catalyst.CatalystTypeConverters$$anonfun$createToCatalystConverter$4.apply(CatalystTypeConverters.scala:178)
> [info]at 
> org.apache.spark.sql.execution.RDDConversions$$anonfun$rowToRowRdd$1$$anonfun$apply$2.apply(ExistingRDD.scala:62)
> [info]at 
> org.apache.spark.sql.execution.RDDConversions$$anonfun$rowToRowRdd$1$$anonfun$apply$2.apply(ExistingRDD.scala:59)
> [info]at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> [info]at scala.collection.Iterator$$anon$11.next(Iterator.scala:328)
> [info]at scala.collection.Iterator$class.foreach(Iterator.scala:727)
> [info]at 
> scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
> [info]at 
> scala.collection.generic.Growable$class.$plus$plus$eq(Growable.scala:48)
> [info]at 
> scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:103)
> [info]at 
> scala.collection.mutable.ArrayBuffer.$plus$plus$eq(ArrayBuffer.scala:47)
> [info]at 
> scala.collection.TraversableOnce$class.to(TraversableOnce.scala:273)
> [info]at scala.collection.AbstractIterator.to(Iterator.scala:1157)
> [info]at 
> scala.collection.TraversableOnce$class.toBuffer(TraversableOnce.scala:265)
> [info]at 
> scala.collection.AbstractIterator.toBuffer(Iterator.scala:1157)
> [info]at 
> scala.collection.TraversableOnce$class.toArray(TraversableOnce.scala:252)
> [info]at 
> scala.collection.AbstractIterator.toArray(Iterator.scala:1157)
> [info]at 
> org.apache.spark.rdd.RDD$$anonfun$collect$1$$anonfun$12.apply(RDD.scala:885)
> [info]at 
> org.apache.spark.rdd.RDD$$anonfun$collect$1$$anonfun$12.apply(RDD.scala:885)
> [info]at 
> org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1765)
> [info]at 
> org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1765)
> [info]at 
> org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:63)
> [info]at org.apache.spark.scheduler.Task.run(Task.scala:70)
> [info]at 
> org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:213)
> [info]at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> [info]at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> [info]at java.lang.Thread.run(Thread.java:745)
> [info] 
> [info] Driver stacktrace:
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler.org$apache$spark$scheduler$DAGScheduler$$failJobAndIndependentStages(DAGScheduler.scala:1266)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1257)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler$$anonfun$abortStage$1.apply(DAGScheduler.scala:1256)
> [info]   at 
> scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59)
> [info]   at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler.abortStage(DAGScheduler.scala:1256)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:730)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler$$anonfun$handleTaskSetFailed$1.apply(DAGScheduler.scala:730)
> [info]   at scala.Option.foreach(Option.scala:236)
> [info]   at 
> org.apache.spark.scheduler.DAGScheduler.handleTaskSetFailed(DAGScheduler.scala:730)
> [info]   ...



--
This message was sent by Atlassian JIRA
(v6.

[GitHub] geode issue #557: add GfshParserRule to facilitate command unit test

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/557
  
Looks like travis-ci failed.  LGTM as soon as travis passes 


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

[jira] [Resolved] (GEODE-2979) Adding server after defining Lucene index results in error

[Diane Hardman (JIRA)]

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

Diane Hardman resolved GEODE-2979.
--
Resolution: Duplicate

Resolving this because: 
1. Correct sequence for adding servers is now documented for Geode 1.2.0
2. Analysis of code changes for future fix is provided in GEODE-3026

> Adding server after defining Lucene index results in error
> --
>
> Key: GEODE-2979
> URL: https://issues.apache.org/jira/browse/GEODE-2979
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>  Labels: workaround
>
> Here are the gfsh commands I used:
> {noformat}
> ## start locator
> start locator --name=locator1 --port=12345
> ## start first server
> start server --name=server50505 --server-port=50505 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> ## create lucene index on region testRegion
> create lucene index --name=testIndex --region=testRegion 
> --field=__REGION_VALUE_FIELD
> ## start second server
> start server --name=server50506 --server-port=50506 
> --locators=localhost[12345] --start-rest-api --http-service-port=8080 
> --http-service-bind-address=localhost
> ## list indexes - NOTE lucene index only listed on first server
> gfsh>list members
>Name | Id
> --- | -
> locator1| 192.168.1.57(locator1:60525:locator):1024
> server50505 | 192.168.1.57(server50505:60533):1025
> server50506 | 192.168.1.57(server50506:60587):1026
> gfsh>list lucene indexes --with-stats
> Index Name | Region Path | Server Name | Inde.. | Field Anal.. | Status  | 
> Query Executions | Updates | Commits | Documents
> -- | --- | --- | -- |  | --- | 
>  | --- | --- | -
> testIndex  | /testRegion | server50505 | [__R.. | {__REGION_.. | Defined | NA 
>   | NA  | NA  | NA
> ## Create region testRegion
> gfsh>create region --name=testRegion --type=PARTITION_REDUNDANT_PERSISTENT
>   Member| Status
> --- | 
> 
> server50506 | ERROR: Must create Lucene index testIndex on region /testRegion 
> because it is defined in another member.
> server50505 | Region "/testRegion" created on "server50505"
> ## Add data to region - NOTE this causes a crash with an NPE
> gfsh>put --key=1 --value=value1 --region=testRegion
> Exception in thread "Gfsh Launcher" java.lang.NoClassDefFoundError: 
> org/apache/commons/collections/CollectionUtils
>   at 
> org.apache.geode.management.internal.cli.commands.DataCommands.put(DataCommands.java:895)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
>   at 
> org.apache.geode.management.internal.cli.remote.RemoteExecutionStrategy.execute(RemoteExecutionStrategy.java:91)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandProcessor.executeCommand(CommandProcessor.java:113)
>   at 
> org.apache.geode.management.internal.cli.remote.CommandStatementImpl.process(CommandStatementImpl.java:71)
>   at 
> org.apache.geode.management.internal.cli.remote.MemberCommandService.processCommand(MemberCommandService.java:52)
>   at 
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1597)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:404)
>   at 
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:397)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:71)
>   at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:275)
>   at 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:193)
>   at

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

[Fred Krone (JIRA)]

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

Fred Krone updated GEODE-3027:
--
Affects Version/s: 1.2.0

> 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: docs, regions
>Affects Versions: 1.2.0
>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.
> Done
> Implement PartitionResolver for delimited String keys.
> 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)

[jira] [Updated] (GEODE-3029) Tomcat Install Documentation has incorrect required JARs

[Joey McAllister (JIRA)]

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

Joey McAllister updated GEODE-3029:
---
Description: 
This page 
(https://geode.apache.org/docs/guide/11/tools_modules/http_session_mgmt/tomcat_installing_the_module.html)
 has the incorrect required JARs needed to install tomcat with geode.

Currently the list is:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar

The correct list should be:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar
commons-lang jar
shiro-core jar

  was:
This page 
(http://gemfire.docs.pivotal.io/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html)
 has the incorrect required JARs needed to install tomcat with geode.

Currently the list is:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar

The correct list should be:
antlr jar
fastutil jar
geode-core jar
javax.transaction-api jar
jgroups jar
log4j-api jar
log4j-core jar
log4j-jul jar
commons-lang jar
shiro-core jar


> Tomcat Install Documentation has incorrect required JARs
> 
>
> Key: GEODE-3029
> URL: https://issues.apache.org/jira/browse/GEODE-3029
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: David Anuta
> Fix For: 1.2.0
>
>
> This page 
> (https://geode.apache.org/docs/guide/11/tools_modules/http_session_mgmt/tomcat_installing_the_module.html)
>  has the incorrect required JARs needed to install tomcat with geode.
> Currently the list is:
> antlr jar
> fastutil jar
> geode-core jar
> javax.transaction-api jar
> jgroups jar
> log4j-api jar
> log4j-core jar
> log4j-jul jar
> The correct list should be:
> antlr jar
> fastutil jar
> geode-core jar
> javax.transaction-api jar
> jgroups jar
> log4j-api jar
> log4j-core jar
> log4j-jul jar
> commons-lang jar
> shiro-core jar



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

Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Ken Howe]

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

Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
Patrick Rhomberg, and Swapnil Bawaskar.


Repository: geode


Description
---

GEODE-2420: add file-size-limit param to the ExportLogsController


Diffs
-

  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
 0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
  
geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
 a369c6e1ffb330715fbde2cd69d023ed36f133ad 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 16549e70bbebf4390bb73a481274e92ca6cad035 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
 44a036298e0991c880fc552596d296e104b97ca1 


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


Testing
---

Precheckin started


Thanks,

Ken Howe

[jira] [Commented] (GEODE-269) Remove deprecated methods on FunctionService

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-269 : Fixing RollingUpgrade2DUnitTest. After removing deprecated API 
withArgs, setArgument alternative API is not available in older version of 
server causing NoSuchMethodFound exception. The role of setArgument with 
function is passing class name to load inside the function. As the relevant 
function is used on in the context of this test, instead of using setArgument 
method made class name as a field in GetDataSerializableFunction.


> Remove deprecated methods on FunctionService
> 
>
> Key: GEODE-269
> URL: https://issues.apache.org/jira/browse/GEODE-269
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> FunctionService has a three deprecated methods that should be easy to remove. 
> All the deprecated methods have a DistributedSystem parameter. New flavors of 
> these methods exist that do not take the DistributedSystem since it is known 
> implicitly by the FunctionService.
> Many tests use the deprecated methods but it should be easy to change them.



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

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-265 : Reverting removal deprecation of withArgs from Execution interface.

This closes #509


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[GitHub] geode pull request #509: GEODE-265: Removing deprecated API from Execution i...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-265) Remove deprecated methods on Execution interface

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-265 : Removing deprecated API's from Execution interface.
In addition to execute method variants removed withArgs method which is 
deprecated as well.


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-265 : Removing implementation of methods which are deprecated and are 
removed from Execution interface.


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

[jira] [Commented] (GEODE-269) Remove deprecated methods on FunctionService

[ASF subversion and git services (JIRA)]

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

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

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

GEODE-269 : SpotlessApply changes.


> Remove deprecated methods on FunctionService
> 
>
> Key: GEODE-269
> URL: https://issues.apache.org/jira/browse/GEODE-269
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> FunctionService has a three deprecated methods that should be easy to remove. 
> All the deprecated methods have a DistributedSystem parameter. New flavors of 
> these methods exist that do not take the DistributedSystem since it is known 
> implicitly by the FunctionService.
> Many tests use the deprecated methods but it should be easy to change them.



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

[jira] [Commented] (GEODE-265) Remove deprecated methods on Execution interface

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-265:
--

Github user asfgit closed the pull request at:

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


> Remove deprecated methods on Execution interface
> 
>
> Key: GEODE-265
> URL: https://issues.apache.org/jira/browse/GEODE-265
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Deepak Dixit
>   Original Estimate: 5h
>  Remaining Estimate: 5h
>
> The Execution interface has a number of execute methods that have been 
> deprecated. It looks like these could be easily removed.



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

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

[Darrel Schneider (JIRA)]

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

Darrel Schneider reassigned GEODE-3027:
---

Assignee: Darrel Schneider

> 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: docs, regions
>Affects Versions: 1.2.0
>Reporter: Fred Krone
>Assignee: Darrel Schneider
> Fix For: 1.2.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.
> Done
> Implement PartitionResolver for delimited String keys.
> 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)

[jira] [Created] (GEODE-3031) Extract startLocator and startServer from LauncherLifecycleCommands

[Jared Stewart (JIRA)]

Jared Stewart created GEODE-3031:


 Summary: Extract startLocator and startServer from 
LauncherLifecycleCommands
 Key: GEODE-3031
 URL: https://issues.apache.org/jira/browse/GEODE-3031
 Project: Geode
  Issue Type: Improvement
  Components: gfsh
Reporter: Jared Stewart


LauncherLifecycleCommands is a huge class that contains both startServer and 
startLocator.  We ought to extract those command methods into their own 
classes, and figure out a sensible home for the shared, common methods from 
LauncherLifecycleCommands used by both commands.



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

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

[Darrel Schneider (JIRA)]

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

Darrel Schneider updated GEODE-3027:

Fix Version/s: (was: 1.3.0)
   1.2.0

> 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: docs, regions
>Affects Versions: 1.2.0
>Reporter: Fred Krone
>Assignee: Darrel Schneider
> Fix For: 1.2.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.
> Done
> Implement PartitionResolver for delimited String keys.
> 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: 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 5, 2017, 6:32 p.m.)


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


Changes
---

added a new interface method according review.


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
 84f97de565a8301168f13e1917ea739a8879162c 
  
geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java
 f9fade1cfe8c181b0a0874869a66643c00300f98 
  
geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java
 14784c391212095413c0d577cfc65de7247080b5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 64fafda8437e06de818ead40731818f937c3aef5 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/remote/CommandProcessor.java
 c2c6e1425d71af9d2ea59046b17afd70ad30dd68 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/AccessControlMBean.java
 6514a33e52611994ddc16a58414146ebaad75c65 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/MBeanServerWrapper.java
 fe79efbed0aa7ec9a3d27526df2f4a86794513c2 
  
geode-core/src/main/java/org/apache/geode/management/internal/security/ResourceOperation.java
 db3a1872a87b558772902cf14580f3e14fca97b3 
  geode-core/src/main/java/org/apache/geode/security/ResourcePermission.java 
45da464419779773c9116d824fcf11774bafbd79 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/ResourcePermissionTest.java
 b728b271efb876d471b35e002c5b110919f10fcc 
  
geode-core/src/test/java/org/apache/geode/management/internal/security/TestCommand.java
 3f8f4d9d4ee0a8f9c3385cd66ee20655d126d34d 
  
geode-core/src/test/java/org/apache/geode/security/SimpleSecurityManagerTest.java
 2d6fbcaeb470c79f383626b8e15e3bd8650377dd 
  geode-core/src/test/java/org/apache/geode/security/TestSecurityManager.java 
6080b5de8c4b11f013d0800baf2a1d9f18cb7f1d 
  
geode-core/src/test/resources/org/apache/geode/codeAnalysis/excludedClasses.txt 
9cff80d1982bd30f6ba5d8a61ab7307a69862fd4 
  
geode-web-api/src/main/java/org/apache/geode/rest/internal/web/security/RestSecurityService.java
 80ff719b015ae0ffb5a648fe026bb01bc6128df8 


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

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


Testing
---

precheckin runing


Thanks,

Jinmei Liao

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Jinmei Liao]

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


Ship it!




Ship It!

- Jinmei Liao


On June 5, 2017, 6:09 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 5, 2017, 6:09 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> Patrick Rhomberg, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Jinmei Liao]

> On June 5, 2017, 6:41 p.m., Jinmei Liao wrote:
> > Ship It!

pending precheckin


- Jinmei


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


On June 5, 2017, 6:09 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 5, 2017, 6:09 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> Patrick Rhomberg, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

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

[YehEmily]

Github user YehEmily closed the pull request at:

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


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

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[davebarnes97]

GitHub user davebarnes97 opened a pull request:

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

GEODE-1672 When amount of overflowed persisted data exceeds heap size…

… startup may run out of memory

This PR Documents a newly-added system property, recoverLRUValues, that 
allows the developer to fine-tune restart behavior on persistent regions with 
an LRU eviction policy that saves overflow values to disk. It also picks up a 
few typo and formatting corrections in related text.

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

$ git pull https://github.com/davebarnes97/geode feature/GEODE-1672

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

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


commit 3df55de9fda367ed507f2c2e1dedcdeb76705163
Author: Dave Barnes 
Date:   2017-06-05T18:25:44Z

GEODE-1672 When amount of overflowed persisted data exceeds heap size 
startup may run out of memory




---
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: [DISCUSS] easy string based partitioning

[Darrel Schneider]

I pictured the top level parent region (your customer region) as not having
the StringPrefixPartitionResolver. Instead it would just use string keys
that have no prefix and use the default resolver.
It would be each co-located child region (your order region) that would
have the StringPrefixPartitionResolver and would format its keys to be
"parentKey:childKey". Does that make sense? Will it work?


On Mon, Jun 5, 2017 at 10:06 AM, Barry Oglesby  wrote:

> The top-level region may not have / need a delimiter. If you have a
> customer region and a colocated orders region, the customer region key
> could be the customerId, and the orders region key could be the
> customerId:orderId. The colocation would be on the customerId. In the
> customer region, it doesn't need a delimiter. Is it ok that this idea would
> require one? Maybe the top-level region shouldn't require a delimiter? If
> the StringPrefixPartitionResolver is using key.split(":"), the customer
> region would return the entire key.
>
>
> Thanks,
> Barry Oglesby
>
>
> On Mon, Jun 5, 2017 at 8:46 AM, Jens Deppe  wrote:
>
> > I like the idea of keeping the configuration 'conventional' and thus not
> > requiring any server configuration. As soon as you need to define a regex
> > on the server you might as well be writing PartitionResolver code.
> >
> > As an aside I also think that using regexes to parse keys would also
> > introduce a measurable performance hit.
> >
> > --Jens
> >
> > On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> > wrote:
> >
> > > Whilst I like the idea to make something (and yes,
> > > DelimitedStringPartitionResolver is the simplest), I feel that we
> might
> > > be able to do one better.
> > >
> > > */Could/* one possibly have an /*SPEL*/  > > -framework/docs/current/spring-framework-reference/
> > html/expressions.html>-based
> > > PartitionResolver for this? At least this way, we don't have to rely on
> > > delimiters or a strong knowledge of REGEX.
> > >
> > > IMO, this would provide the greatest bang for buck implementation.
> > >
> > > --Udo
> > >
> > >
> > >
> > >
> > > On 6/2/17 19:15, 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 <
> dschnei...@pivotal.io>
> > >> 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=

Re: [DISCUSS] easy string based partitioning

[Barry Oglesby]

Yes, that makes a lot of sense. Thanks for the clarification.

Thanks,
Barry Oglesby


On Mon, Jun 5, 2017 at 12:06 PM, Darrel Schneider 
wrote:

> I pictured the top level parent region (your customer region) as not having
> the StringPrefixPartitionResolver. Instead it would just use string keys
> that have no prefix and use the default resolver.
> It would be each co-located child region (your order region) that would
> have the StringPrefixPartitionResolver and would format its keys to be
> "parentKey:childKey". Does that make sense? Will it work?
>
>
> On Mon, Jun 5, 2017 at 10:06 AM, Barry Oglesby 
> wrote:
>
> > The top-level region may not have / need a delimiter. If you have a
> > customer region and a colocated orders region, the customer region key
> > could be the customerId, and the orders region key could be the
> > customerId:orderId. The colocation would be on the customerId. In the
> > customer region, it doesn't need a delimiter. Is it ok that this idea
> would
> > require one? Maybe the top-level region shouldn't require a delimiter? If
> > the StringPrefixPartitionResolver is using key.split(":"), the customer
> > region would return the entire key.
> >
> >
> > Thanks,
> > Barry Oglesby
> >
> >
> > On Mon, Jun 5, 2017 at 8:46 AM, Jens Deppe  wrote:
> >
> > > I like the idea of keeping the configuration 'conventional' and thus
> not
> > > requiring any server configuration. As soon as you need to define a
> regex
> > > on the server you might as well be writing PartitionResolver code.
> > >
> > > As an aside I also think that using regexes to parse keys would also
> > > introduce a measurable performance hit.
> > >
> > > --Jens
> > >
> > > On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> > > wrote:
> > >
> > > > Whilst I like the idea to make something (and yes,
> > > > DelimitedStringPartitionResolver is the simplest), I feel that we
> > might
> > > > be able to do one better.
> > > >
> > > > */Could/* one possibly have an /*SPEL*/ <
> https://docs.spring.io/spring
> > > > -framework/docs/current/spring-framework-reference/
> > > html/expressions.html>-based
> > > > PartitionResolver for this? At least this way, we don't have to rely
> on
> > > > delimiters or a strong knowledge of REGEX.
> > > >
> > > > IMO, this would provide the greatest bang for buck implementation.
> > > >
> > > > --Udo
> > > >
> > > >
> > > >
> > > >
> > > > On 6/2/17 19:15, 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 <
> > dschnei...@pivotal.io>
> > > >> 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

Re: [DISCUSS] easy string based partitioning

[Fred Krone]

Cool.  This is what I was thinking too.

Fred

On Jun 5, 2017 12:50 PM, "Barry Oglesby"  wrote:

> Yes, that makes a lot of sense. Thanks for the clarification.
>
> Thanks,
> Barry Oglesby
>
>
> On Mon, Jun 5, 2017 at 12:06 PM, Darrel Schneider 
> wrote:
>
> > I pictured the top level parent region (your customer region) as not
> having
> > the StringPrefixPartitionResolver. Instead it would just use string keys
> > that have no prefix and use the default resolver.
> > It would be each co-located child region (your order region) that would
> > have the StringPrefixPartitionResolver and would format its keys to be
> > "parentKey:childKey". Does that make sense? Will it work?
> >
> >
> > On Mon, Jun 5, 2017 at 10:06 AM, Barry Oglesby 
> > wrote:
> >
> > > The top-level region may not have / need a delimiter. If you have a
> > > customer region and a colocated orders region, the customer region key
> > > could be the customerId, and the orders region key could be the
> > > customerId:orderId. The colocation would be on the customerId. In the
> > > customer region, it doesn't need a delimiter. Is it ok that this idea
> > would
> > > require one? Maybe the top-level region shouldn't require a delimiter?
> If
> > > the StringPrefixPartitionResolver is using key.split(":"), the customer
> > > region would return the entire key.
> > >
> > >
> > > Thanks,
> > > Barry Oglesby
> > >
> > >
> > > On Mon, Jun 5, 2017 at 8:46 AM, Jens Deppe  wrote:
> > >
> > > > I like the idea of keeping the configuration 'conventional' and thus
> > not
> > > > requiring any server configuration. As soon as you need to define a
> > regex
> > > > on the server you might as well be writing PartitionResolver code.
> > > >
> > > > As an aside I also think that using regexes to parse keys would also
> > > > introduce a measurable performance hit.
> > > >
> > > > --Jens
> > > >
> > > > On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer  >
> > > > wrote:
> > > >
> > > > > Whilst I like the idea to make something (and yes,
> > > > > DelimitedStringPartitionResolver is the simplest), I feel that we
> > > might
> > > > > be able to do one better.
> > > > >
> > > > > */Could/* one possibly have an /*SPEL*/ <
> > https://docs.spring.io/spring
> > > > > -framework/docs/current/spring-framework-reference/
> > > > html/expressions.html>-based
> > > > > PartitionResolver for this? At least this way, we don't have to
> rely
> > on
> > > > > delimiters or a strong knowledge of REGEX.
> > > > >
> > > > > IMO, this would provide the greatest bang for buck implementation.
> > > > >
> > > > > --Udo
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 6/2/17 19:15, 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 <
> > > dschnei...@pivotal.io>
> > > > >> 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:

Re: [DISCUSS] Discussions of API changes missing or lost in noise

[Anthony Baker]

Fixed!  Please check iss...@geode.apache.org for JIRA updates.

Anthony

> On Jun 1, 2017, at 3:41 PM, Anthony Baker  wrote:
> 
> There is an iss...@geode.apache.org mailing list but it seems to have been 
> misconfigured last December.  All the JIRA traffic got shunted over to dev@.
> 
> I filed a ticket to fix this: 
> https://issues.apache.org/jira/browse/INFRA-14266
> 
> 
> Anthony
> 
>> On Jun 1, 2017, at 2:09 PM, Dan Smith  wrote:
>> 
>> Hi devs,
>> 
>> This is similar to the discussion John started about keeping track of
>> changes to geode. I'm seeing some changes happening to the public API that
>> I feel like maybe should have a more visible discussion. For example
>> GEODE-2892 (Region.sizeOnServer) or GEODE-3005 (new API for partitioning).
>> 
>> I think we should have a clear policy to send an email with [DISCUSS] in
>> the header to mailing list for changes to the public API, behavior, or
>> dependencies. Or wiki
>> 
>> says that changes should be discussed, but it doesn't really specify how.
>> 
>> Part of the issue is that I find it impossible to keep up with the amount
>> of JIRA noise on the dev list, so just creating a JIRA is not enough for me
>> to notice a new API change. I propose that we segregate all of this
>> automated email onto a separate list, either geode-commits or some new
>> list. I'd like to segregate anything not directly sent by a human - JIRAs,
>> PRs, and reviewboards.
>> 
>> -Dan
> 

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

(Updated June 5, 2017, 8:03 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/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://revie

[GitHub] geode pull request #560: Geode 2818: Adding aliases to any command options t...

[YehEmily]

GitHub user YehEmily opened a pull request:

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

Geode 2818: Adding aliases to any command options that involve "group", 
"member", or "jar"

… "member", "jar" and replace CliString variables with GROUP, MEMBER, 
JAR, etc.

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

$ git pull https://github.com/YehEmily/geode GEODE-2818

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

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


commit 24958612611c293497cec7300856c68f2bfb819a
Author: YehEmily 
Date:   2017-06-05T20:03:39Z

GEODE-2818: add alias to any command's options that involves "group", 
"member", "jar" and replace CliString variables with GROUP, MEMBER, JAR, etc.




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

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[joeymcallister]

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

https://github.com/apache/geode/pull/559#discussion_r120199524
  
--- Diff: 
geode-docs/managing/troubleshooting/system_failure_and_recovery.html.md.erb ---
@@ -276,8 +276,83 @@ find the reason.
 
 Description:
 
-The process discovered that it was not in the distributed system and 
cannot determine why it was removed. The membership coordinator removed the 
member after it failed to respond to an internal are you alive message.
+The process discovered that it was not in the distributed system and 
cannot determine why it was
+removed. The membership coordinator removed the member after it failed to 
respond to an internal are
+you alive message.
--- End diff --

I stumbled on my first reading of this. I'd hyphenate "are-you-alive" here. 


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

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[joeymcallister]

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

https://github.com/apache/geode/pull/559#discussion_r120200477
  
--- Diff: 
geode-docs/managing/troubleshooting/system_failure_and_recovery.html.md.erb ---
@@ -276,8 +276,83 @@ find the reason.
 
 Description:
 
-The process discovered that it was not in the distributed system and 
cannot determine why it was removed. The membership coordinator removed the 
member after it failed to respond to an internal are you alive message.
+The process discovered that it was not in the distributed system and 
cannot determine why it was
+removed. The membership coordinator removed the member after it failed to 
respond to an internal are
+you alive message.
 
 Response:
 
 The operator should examine the locator processes and logs.
+
+##  
Restart Fails Due To Out-of-Memory Error
+
+This section describes a restart failure that can occur when the stopped 
system is one that was configured with persistent regions. Specifically:
+
+- Some of the regions of the recovering system, when running, were 
configured as PERSISTENT regions, which means that they save their data to disk.
+- At least one of the persistent regions was configured to evict least 
recently used (LRU) data by overflowing values to disk.
+
+### How Data is Recovered From Persistent Regions
+
+Data recovery, upon restart, always recovers keys. You can configure 
whether and how the system
+recovers the values associated with those keys to populate the system 
cache.
+
+**Value Recovery**
+
+- Recovering all values immediately during startup slows the startup time 
but results in consistent
+read performance after the startup on a "hot" cache.
+
+- Recovering no values means quicker startup but a "cold" cache, so the 
first retrieval of each value will read from disk.
+
+- Retrieving values asynchronously in a background thread allows a 
relatively quick startup on a "warm" cache
+that will eventually recover every value.
+
+**Retrieve or Ignore LRU values**
+
+When a system with Persistent LRU regions shuts down, the system does not 
record which of the values
--- End diff --

lowercase "persistent"


---
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 59811: GEODE-2420: add file-size-limit param to the ExportLogsController

[Jinmei Liao]

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



Actually I was looking at the various size checks implemented in 
ExportLogsCommand, looks like the flow is this:
1. go to each member, find out what's the combined log size that's going to be 
streamed to the locator, and check if the size limit exeedes the locator's 
available disk space.
2. If not, export the logs down to the locator, and check if the final zip file 
exceeds the user-specified file-size-limit.

I have a question on check #1, I thought we should also check the estimated 
size against the user-specified value as well.

- Jinmei Liao


On June 5, 2017, 6:09 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59811/
> ---
> 
> (Updated June 5, 2017, 6:09 p.m.)
> 
> 
> Review request for geode, Emily Yeh, Jinmei Liao, Jared Stewart, Kirk Lund, 
> Patrick Rhomberg, and Swapnil Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2420: add file-size-limit param to the ExportLogsController
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  0ff780cbf66937d8ececfb3a2d0789ee485b9b62 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/web/controllers/ExportLogController.java
>  a369c6e1ffb330715fbde2cd69d023ed36f133ad 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  16549e70bbebf4390bb73a481274e92ca6cad035 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  8609b3aaf0a0eb1ba903bd39c64103f9510a6a78 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsStatsDUnitTest.java
>  44a036298e0991c880fc552596d296e104b97ca1 
> 
> 
> Diff: https://reviews.apache.org/r/59811/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin started
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: [DISCUSS] easy string based partitioning

[Udo Kohlmeyer]

My concern with this approach is that we provide an implementation that 
might be a white elephant and only used by a 1% user base. In addition 
to that, it does really restrict the user on his keys.


Whereas something a little more configurable, like a SPEL 
implementation, would provide a lot more flexibility. Which means that 
one could easily change the partition resolver expression upon region 
creation/configuration.


--Udo


On 6/5/17 08:46, Jens Deppe wrote:

I like the idea of keeping the configuration 'conventional' and thus not
requiring any server configuration. As soon as you need to define a regex
on the server you might as well be writing PartitionResolver code.

As an aside I also think that using regexes to parse keys would also
introduce a measurable performance hit.

--Jens

On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer  wrote:


Whilst I like the idea to make something (and yes,
DelimitedStringPartitionResolver is the simplest), I feel that we might
be able to do one better.

*/Could/* one possibly have an /*SPEL*/ -based
PartitionResolver for this? At least this way, we don't have to rely on
delimiters or a strong knowledge of REGEX.

IMO, this would provide the greatest bang for buck implementation.

--Udo




On 6/2/17 19:15, 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.StringPrefixPart
itionResolver

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.

[GitHub] geode issue #559: GEODE-1672 When amount of overflowed persisted data exceed...

[joeymcallister]

Github user joeymcallister commented on the issue:

https://github.com/apache/geode/pull/559
  
Added a couple of small notes for review, then +1. Looks great, Dave!


---
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: [DISCUSS] easy string based partitioning

[Michael Stolz]

Yep that will work.

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

On Jun 5, 2017 12:06 PM, "Darrel Schneider"  wrote:

> I pictured the top level parent region (your customer region) as not having
> the StringPrefixPartitionResolver. Instead it would just use string keys
> that have no prefix and use the default resolver.
> It would be each co-located child region (your order region) that would
> have the StringPrefixPartitionResolver and would format its keys to be
> "parentKey:childKey". Does that make sense? Will it work?
>
>
> On Mon, Jun 5, 2017 at 10:06 AM, Barry Oglesby 
> wrote:
>
> > The top-level region may not have / need a delimiter. If you have a
> > customer region and a colocated orders region, the customer region key
> > could be the customerId, and the orders region key could be the
> > customerId:orderId. The colocation would be on the customerId. In the
> > customer region, it doesn't need a delimiter. Is it ok that this idea
> would
> > require one? Maybe the top-level region shouldn't require a delimiter? If
> > the StringPrefixPartitionResolver is using key.split(":"), the customer
> > region would return the entire key.
> >
> >
> > Thanks,
> > Barry Oglesby
> >
> >
> > On Mon, Jun 5, 2017 at 8:46 AM, Jens Deppe  wrote:
> >
> > > I like the idea of keeping the configuration 'conventional' and thus
> not
> > > requiring any server configuration. As soon as you need to define a
> regex
> > > on the server you might as well be writing PartitionResolver code.
> > >
> > > As an aside I also think that using regexes to parse keys would also
> > > introduce a measurable performance hit.
> > >
> > > --Jens
> > >
> > > On Mon, Jun 5, 2017 at 8:21 AM, Udo Kohlmeyer 
> > > wrote:
> > >
> > > > Whilst I like the idea to make something (and yes,
> > > > DelimitedStringPartitionResolver is the simplest), I feel that we
> > might
> > > > be able to do one better.
> > > >
> > > > */Could/* one possibly have an /*SPEL*/ <
> https://docs.spring.io/spring
> > > > -framework/docs/current/spring-framework-reference/
> > > html/expressions.html>-based
> > > > PartitionResolver for this? At least this way, we don't have to rely
> on
> > > > delimiters or a strong knowledge of REGEX.
> > > >
> > > > IMO, this would provide the greatest bang for buck implementation.
> > > >
> > > > --Udo
> > > >
> > > >
> > > >
> > > >
> > > > On 6/2/17 19:15, 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 <
> > dschnei...@pivotal.io>
> > > >> 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 re

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[asfgit]

Github user asfgit closed the pull request at:

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


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

[GitHub] geode pull request #561: GEODE-3033: Fixing NPE when jarFileNames is null in...

[YehEmily]

GitHub user YehEmily opened a pull request:

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

GEODE-3033: Fixing NPE when jarFileNames is null in 
ClusterConfigurationLoader

Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

$ git pull https://github.com/YehEmily/geode GEODE-3033

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

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


commit b0044cdc9e7fbfc8db421b1af0d511df77fdbc1a
Author: YehEmily 
Date:   2017-06-05T21:21:31Z

GEODE-3033: Fixing NPE when jarFileNames is null in 
ClusterConfigurationLoader




---
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 #561: GEODE-3033: Fixing NPE when jarFileNames is null in Cluste...

[YehEmily]

Github user YehEmily commented on the issue:

https://github.com/apache/geode/pull/561
  
Precheckin in progress!


---
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 59819: GEODE-3034 java.lang.ArrayIndexOutOfBoundsException: 0 on auto-reconnect attempt with multicast enabled

[Bruce Schuchardt]

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

Review request for geode, Galen O'Sullivan, Hitesh Khamesra, and Udo Kohlmeyer.


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


Repository: geode


Description
---

A bug in JGroups causes this exception.  A workaround is to add a non-usable 
UUID-based address to the view that we use to reinialize JGroups during an 
auto-reconnect attempt.  We've sent this issue to the JGroups email list.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/messenger/JGroupsMessenger.java
 b07aa591ccc4a559f4f8801fae3809a670dd359c 


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


Testing
---

Since this involves multicast we can't create a unit test to verify the fix, 
though we did so on a machine with mcast support to make sure the fix is 
correct.


Thanks,

Bruce Schuchardt

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[dschneider-pivotal]

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/559#discussion_r120222821
  
--- Diff: 
geode-docs/managing/troubleshooting/system_failure_and_recovery.html.md.erb ---
@@ -276,8 +276,83 @@ find the reason.
 
 Description:
 
-The process discovered that it was not in the distributed system and 
cannot determine why it was removed. The membership coordinator removed the 
member after it failed to respond to an internal are you alive message.
+The process discovered that it was not in the distributed system and 
cannot determine why it was
+removed. The membership coordinator removed the member after it failed to 
respond to an internal 
+are-you-alive message.
 
 Response:
 
 The operator should examine the locator processes and logs.
+
+##  
Restart Fails Due To Out-of-Memory Error
+
+This section describes a restart failure that can occur when the stopped 
system is one that was configured with persistent regions. Specifically:
+
+- Some of the regions of the recovering system, when running, were 
configured as PERSISTENT regions, which means that they save their data to disk.
+- At least one of the persistent regions was configured to evict least 
recently used (LRU) data by overflowing values to disk.
+
+### How Data is Recovered From Persistent Regions
+
+Data recovery, upon restart, always recovers keys. You can configure 
whether and how the system
+recovers the values associated with those keys to populate the system 
cache.
+
+**Value Recovery**
+
+- Recovering all values immediately during startup slows the startup time 
but results in consistent
+read performance after the startup on a "hot" cache.
+
+- Recovering no values means quicker startup but a "cold" cache, so the 
first retrieval of each value will read from disk.
+
+- Retrieving values asynchronously in a background thread allows a 
relatively quick startup on a "warm" cache
+that will eventually recover every value.
+
+**Retrieve or Ignore LRU values**
+
+When a system with persistent LRU regions shuts down, the system does not 
record which of the values
+were recently used. On subsequent startup, if values are recovered into an 
LRU region they may be
+the least recently used instead of the most recently used. Also, if LRU 
values are recovered on a
+heap or an off-heap LRU region, it is possible that the LRU memory limit 
will be exceeded, resulting
+in an `OutOfMemoryException` during recovery. For these reasons, LRU value 
recovery can be treated
+differently than non-LRU values.
+
+## Default Recovery Behavior for Persistent Regions
+
+The default behavior is for the system to recover all keys, then 
asynchronously recover all data
+values that were resident, leaving LRU values unrecovered. This default 
strategy is best for
--- End diff --

drop "that were resident"


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

[GitHub] geode pull request #559: GEODE-1672 When amount of overflowed persisted data...

[dschneider-pivotal]

Github user dschneider-pivotal commented on a diff in the pull request:

https://github.com/apache/geode/pull/559#discussion_r120224399
  
--- Diff: 
geode-docs/managing/troubleshooting/system_failure_and_recovery.html.md.erb ---
@@ -276,8 +276,83 @@ find the reason.
 
 Description:
 
-The process discovered that it was not in the distributed system and 
cannot determine why it was removed. The membership coordinator removed the 
member after it failed to respond to an internal are you alive message.
+The process discovered that it was not in the distributed system and 
cannot determine why it was
+removed. The membership coordinator removed the member after it failed to 
respond to an internal 
+are-you-alive message.
 
 Response:
 
 The operator should examine the locator processes and logs.
+
+##  
Restart Fails Due To Out-of-Memory Error
+
+This section describes a restart failure that can occur when the stopped 
system is one that was configured with persistent regions. Specifically:
+
+- Some of the regions of the recovering system, when running, were 
configured as PERSISTENT regions, which means that they save their data to disk.
+- At least one of the persistent regions was configured to evict least 
recently used (LRU) data by overflowing values to disk.
+
+### How Data is Recovered From Persistent Regions
+
+Data recovery, upon restart, always recovers keys. You can configure 
whether and how the system
+recovers the values associated with those keys to populate the system 
cache.
+
+**Value Recovery**
+
+- Recovering all values immediately during startup slows the startup time 
but results in consistent
+read performance after the startup on a "hot" cache.
+
+- Recovering no values means quicker startup but a "cold" cache, so the 
first retrieval of each value will read from disk.
+
+- Retrieving values asynchronously in a background thread allows a 
relatively quick startup on a "warm" cache
+that will eventually recover every value.
+
+**Retrieve or Ignore LRU values**
+
+When a system with persistent LRU regions shuts down, the system does not 
record which of the values
+were recently used. On subsequent startup, if values are recovered into an 
LRU region they may be
+the least recently used instead of the most recently used. Also, if LRU 
values are recovered on a
+heap or an off-heap LRU region, it is possible that the LRU memory limit 
will be exceeded, resulting
+in an `OutOfMemoryException` during recovery. For these reasons, LRU value 
recovery can be treated
+differently than non-LRU values.
+
+## Default Recovery Behavior for Persistent Regions
+
+The default behavior is for the system to recover all keys, then 
asynchronously recover all data
+values that were resident, leaving LRU values unrecovered. This default 
strategy is best for
+most applications, because it strikes a balance between recovery speed and 
cache completeness.
+
+### Configuring Recovery of Persistent Regions
+
+Three Java system parameters allow the developer to control the recovery 
behavior for persistent regions:
+
+- `gemfire.disk.recoverValues`
+
+  Default = `true`, recover values. If `false`, recover only keys, do not 
recover values.
+
+  *How used:* When `true`, recovery of the values "warms up" the cache so 
data retrievals will find
+  their values in the cache, without causing time consuming disk accesses. 
When `false`, shortens
+  recovery time so the system becomes available for use sooner, but the 
first retrieval on each key
+  will require a disk read.
+
+- `gemfire.disk.recoverLruValues`
+
+  Default = `false`, do not recover LRU values. If `true`, recover LRU 
values. If
+  `gemfire.disk.recoverValues` is `false`, then 
`gemfire.disk.recoverLruValues` is ignored, since
+  no values are recovered.
+
+  *How used:* When `false`, shortens recovery time by ignoring LRU values. 
When `true`, restores
+  more data values to the cache. Recovery of the LRU values increases heap 
memory usage and
+  could cause an out-of-memory error, preventing the system from 
restarting.
+
+- `gemfire.disk.recoverValuesSync`
+
+  Default = `false`, recover values by an asynchronous background process. 
If `true`, values are
+  recovered synchronously, and recovery is not complete until all values 
have been retrieved.  If
+  `gemfire.disk.recoverValues` is `false`, then 
`gemfire.disk.recoverValuesSync` is ignored since
+  no values are recovered.
+
+  *How used:* When `false`, allows the system to become available sooner, 
but some time must elapse
+  before the entire cache is refreshed. Some key retrievals will require 
disk access, and some will not.
--- End diff --

   

[GitHub] geode pull request #562: GEODE-3025: GET operation before Lucene query

[nabarunnag]

GitHub user nabarunnag opened a pull request:

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

GEODE-3025: GET operation before Lucene query

* To allow Lucene queries in single hop with transaction enabled mode, 
the client must get the metadata about the regions.
* A Get operation will asynchronously fetch the metadata and the Lucene 
query will not throw an exception.

@jhuynh1 
Thank you for submitting a contribution to Apache Geode.

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

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

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

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

- [ ] Does `gradlew build` run cleanly?

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

- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?

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


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

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

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

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


commit bb8e94ffa340a82fe3304959f0b4ddd20edaad85
Author: nabarun 
Date:   2017-06-05T21:44:39Z

GEODE-3025: GET operation before Lucene query

* To allow Lucene queries in single hop with transaction enabled mode, 
the client must get the metadata about the regions.
* A Get operation will asynchronously fetch the metadata and the Lucene 
query will not throw an exception.




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

[GitHub] geode pull request #563: Add a bunch of .proto definitions to the new protoc...

[galen-pivotal]

GitHub user galen-pivotal opened a pull request:

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

Add a bunch of .proto definitions to the new protocol.

These are mostly unimplemented, and some, especially GetServers, may not
make it through in this form. It's a good sketch for feature parity with
the REST API, though.

This is on a feature branch, so I'm going to skip the normal test list. 
Please review and comment. @udo @hiteshk25 @bschuchardt and Brian and 
Alexander, whose github names I can't seem to find.

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

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

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

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


commit 90b10109d260c881c3179b72470db1bf4ef14f0c
Author: Galen OSullivan 
Date:   2017-06-05T22:43:33Z

Add a bunch of .proto definitions to the new protocol.

These are mostly unimplemented, and some, especially GetServers, may not
make it through in this form. It's a good sketch for feature parity with
the REST API, though.




---
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 #563: Add a bunch of .proto definitions to the new protocol.

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/563
  
@udo want to merge this?


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

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

[GitHub] geode issue #559: GEODE-1672 When amount of overflowed persisted data exceed...

[davebarnes97]

Github user davebarnes97 commented on the issue:

https://github.com/apache/geode/pull/559
  
Thanks, Darrel. Changes incorporated.

On Mon, Jun 5, 2017 at 3:19 PM, Darrel Schneider 
wrote:

> *@dschneider-pivotal* commented on this pull request.
>
> This looks good. I just had two comments
> --
>
> In geode-docs/managing/troubleshooting/system_
> failure_and_recovery.html.md.erb
> :
>
> > +- Retrieving values asynchronously in a background thread allows a 
relatively quick startup on a "warm" cache
> +that will eventually recover every value.
> +
> +**Retrieve or Ignore LRU values**
> +
> +When a system with persistent LRU regions shuts down, the system does 
not record which of the values
> +were recently used. On subsequent startup, if values are recovered into 
an LRU region they may be
> +the least recently used instead of the most recently used. Also, if LRU 
values are recovered on a
> +heap or an off-heap LRU region, it is possible that the LRU memory limit 
will be exceeded, resulting
> +in an `OutOfMemoryException` during recovery. For these reasons, LRU 
value recovery can be treated
> +differently than non-LRU values.
> +
> +## Default Recovery Behavior for Persistent Regions
> +
> +The default behavior is for the system to recover all keys, then 
asynchronously recover all data
> +values that were resident, leaving LRU values unrecovered. This default 
strategy is best for
>
> drop "that were resident"
> --
>
> In geode-docs/managing/troubleshooting/system_
> failure_and_recovery.html.md.erb
> :
>
> > +  `gemfire.disk.recoverValues` is `false`, then 
`gemfire.disk.recoverLruValues` is ignored, since
> +  no values are recovered.
> +
> +  *How used:* When `false`, shortens recovery time by ignoring LRU 
values. When `true`, restores
> +  more data values to the cache. Recovery of the LRU values increases 
heap memory usage and
> +  could cause an out-of-memory error, preventing the system from 
restarting.
> +
> +- `gemfire.disk.recoverValuesSync`
> +
> +  Default = `false`, recover values by an asynchronous background 
process. If `true`, values are
> +  recovered synchronously, and recovery is not complete until all values 
have been retrieved.  If
> +  `gemfire.disk.recoverValues` is `false`, then 
`gemfire.disk.recoverValuesSync` is ignored since
> +  no values are recovered.
> +
> +  *How used:* When `false`, allows the system to become available 
sooner, but some time must elapse
> +  before the entire cache is refreshed. Some key retrievals will require 
disk access, and some will not.
>
> change "the entire cache is refreshed" to "all values have been read from
> disk into cache memory"
>
> —
> You are receiving this because you authored the thread.
> 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-nightly #858

[Apache Jenkins Server]

See 


Changes:

[jiliao] GEODE-2981: Fix the line feed code of the test expected value

[nnag] GEODE-265 : Removing deprecated API's from Execution interface. In

[nnag] GEODE-265 : Removing implementation of methods which are deprecated and

[nnag] GEODE-269 : Fixing RollingUpgrade2DUnitTest. After removing deprecated

[nnag] GEODE-269 : SpotlessApply changes.

[nnag] GEODE-265 : Reverting removal deprecation of withArgs from Execution

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

[dbarnes] GEODE-1672: When amount of overflowed persisted data exceeds heap size

--
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on mesos2 (mesos s390x) in workspace 

Cloning the remote Git repository
Cloning repository https://git-wip-us.apache.org/repos/asf/geode.git
 > git init  # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git --version # timeout=10
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # 
 > timeout=10
 > git config remote.origin.url 
 > https://git-wip-us.apache.org/repos/asf/geode.git # timeout=10
Fetching upstream changes from https://git-wip-us.apache.org/repos/asf/geode.git
 > git fetch --tags --progress 
 > https://git-wip-us.apache.org/repos/asf/geode.git 
 > +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/develop^{commit} # timeout=10
Checking out Revision 1e11c5cc96c22123988e8d3480c0ebb2f2c2df6a 
(refs/remotes/origin/develop)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 1e11c5cc96c22123988e8d3480c0ebb2f2c2df6a
 > git branch -a -v --no-abbrev # timeout=10
 > git checkout -b develop 1e11c5cc96c22123988e8d3480c0ebb2f2c2df6a
 > git rev-list 74c7bbcd07a70e85b14956fa27d0c50c023a7a05 # timeout=10
[Geode-nightly] $ /bin/bash -xe /tmp/hudson5782909569138838446.sh
+ git clean -d -f gemfire-pulse/src/main/resources/
[Gradle] - Launching build.
[Geode-nightly] $  
--no-daemon clean precheckin distTar distZip uploadArchives -xflakyTest

ERROR: JAVA_HOME is set to an invalid directory: 
/home/jenkins/tools/java/latest1.8

Please set the JAVA_HOME variable in your environment to match the
location of your Java installation.

Build step 'Invoke Gradle script' changed build result to FAILURE
Build step 'Invoke Gradle script' marked build as failure
Archiving artifacts
Recording test results
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Not sending mail to unregistered user e...@pivotal.io
Not sending mail to unregistered user jil...@pivotal.io

Build failed in Jenkins: Geode-release #54

[Apache Jenkins Server]

See 

--
[...truncated 145.31 KB...]
java.lang.AssertionError
at 
org.apache.geode.redis.RedisServerTest.initializeRedisCreatesThreeRegions(RedisServerTest.java:54)

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

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

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq:spotlessJavaCheck
:geode-cq:spotlessCheck
:geode-cq:test
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq: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:compileTestJava
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.pom
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-parent/2.4.0/randomizedtesting-parent-2.4.0.pom
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-test-framework/6.4.1/lucene-test-framework-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-codecs/6.4.1/lucene-codecs-6.4.1.jar
Download 
https://repo1.maven.org/maven2/org/apache/lucene/lucene-analyzers-phonetic/6.4.1/lucene-analyzers-phonetic-6.4.1.jar
Download 
https://repo1.maven.org/maven2/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.4.0/randomizedtesting-runner-2.4.0.jar
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene: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:compileTestJava
Download 
https://repo1.maven.org/maven2/com/c

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

[galen-pivotal]

Github user galen-pivotal commented on the issue:

https://github.com/apache/geode/pull/474
  
@masaki-yamakawa [Stack 
overflow](https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit)
 suggests that you can trigger a build by closing and reopening the PR. I don't 
have write access, so I can't kick it myself. Sorry for the slow response.


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