[jira] [Commented] (GEODE-2980) Code Cleanup : Remove redundant modifier from the Interface definition

[ASF GitHub Bot (JIRA)]

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

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

GitHub user davinash opened a pull request:

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

GEODE-2980: All the methods in an interface are implicitly public and 
abstract.

All fields in the interface are implicitly public, static and final.
Removing this from all the interface.
Pre-checkin pass.

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?
Not required for this change

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

### 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/davinash/geode feature/GEODE-2980

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

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


commit 8e6fdeec35ab62b3913dab9292fefe604fa340ad
Author: Avinash 
Date:   2017-05-23T03:55:02Z

All the methods in an interface are implicitly public and abstract.
All fields in the interface are implicitly public, static and final.
Removing this from all the interface.




> Code Cleanup : Remove redundant modifier from the Interface definition
> --
>
> Key: GEODE-2980
> URL: https://issues.apache.org/jira/browse/GEODE-2980
> Project: Geode
>  Issue Type: Task
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
>
> All methods in an interface are implicitly {{public}} and {{abstract}}
> All fields in an interface are implicitly {{public}}, {{static}} and 
> {{final}}.
> We have almost in all the interface public modifier for all the methods in 
> the Interfaces, we should remove the same.



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

[GitHub] geode pull request #529: GEODE-2980: All the methods in an interface are imp...

[davinash]

GitHub user davinash opened a pull request:

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

GEODE-2980: All the methods in an interface are implicitly public and 
abstract.

All fields in the interface are implicitly public, static and final.
Removing this from all the interface.
Pre-checkin pass.

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?
Not required for this change

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

### 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/davinash/geode feature/GEODE-2980

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

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


commit 8e6fdeec35ab62b3913dab9292fefe604fa340ad
Author: Avinash 
Date:   2017-05-23T03:55:02Z

All the methods in an interface are implicitly public and abstract.
All fields in the interface are implicitly public, static and final.
Removing this from all the interface.




---
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-2962) Need more friendly locator's log message when executing "gfsh compact disk-store" command

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/525#discussion_r118150229
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -485,9 +485,14 @@ public Result compactDiskStore(
   memberCompactInfo.clear();
 }
 String notExecutedMembers = 
CompactRequest.getNotExecutedMembers();
+if (notExecutedMembers != null && 
!notExecutedMembers.isEmpty()) {
+  notExecutedMembers = "but was not send to " + 
notExecutedMembers;
+} else {
+  notExecutedMembers = "all the members";
--- End diff --

Hello Darrel,

I remove redundant log message according to your suggestion.


> Need more friendly locator's log message when executing "gfsh compact 
> disk-store" command
> -
>
> Key: GEODE-2962
> URL: https://issues.apache.org/jira/browse/GEODE-2962
> Project: Geode
>  Issue Type: Wish
>  Components: persistence
>Reporter: Akihiro Kitada
>Priority: Minor
>
> When executing "gfsh compact disk-store" command, then we currently see the 
> following kind of issue if the command is successfully executed for all the 
> target members.
> {noformat}
> compact disk-store "DEFAULT" message was scheduled to be sent to but was not 
> send to null
> {noformat}
> This message is not friendly to know what was going on.
> Need more friendly log message.



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

[GitHub] geode pull request #525: GEODE-2962: Add more messages for compact disk-stor...

[AkihiroKitada]

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

https://github.com/apache/geode/pull/525#discussion_r118150229
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -485,9 +485,14 @@ public Result compactDiskStore(
   memberCompactInfo.clear();
 }
 String notExecutedMembers = 
CompactRequest.getNotExecutedMembers();
+if (notExecutedMembers != null && 
!notExecutedMembers.isEmpty()) {
+  notExecutedMembers = "but was not send to " + 
notExecutedMembers;
+} else {
+  notExecutedMembers = "all the members";
--- End diff --

Hello Darrel,

I remove redundant log message according to your suggestion.


---
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] [Assigned] (GEODE-2980) Code Cleanup : Remove redundant modifier from the Interface definition

[Avinash Dongre (JIRA)]

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

Avinash Dongre reassigned GEODE-2980:
-

Assignee: Avinash Dongre

> Code Cleanup : Remove redundant modifier from the Interface definition
> --
>
> Key: GEODE-2980
> URL: https://issues.apache.org/jira/browse/GEODE-2980
> Project: Geode
>  Issue Type: Task
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
>
> All methods in an interface are implicitly {{public}} and {{abstract}}
> All fields in an interface are implicitly {{public}}, {{static}} and 
> {{final}}.
> We have almost in all the interface public modifier for all the methods in 
> the Interfaces, we should remove the same.



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

[jira] [Created] (GEODE-2980) Code Cleanup : Remove redundant modifier from the Interface definition

[Avinash Dongre (JIRA)]

Avinash Dongre created GEODE-2980:
-

 Summary: Code Cleanup : Remove redundant modifier from the 
Interface definition
 Key: GEODE-2980
 URL: https://issues.apache.org/jira/browse/GEODE-2980
 Project: Geode
  Issue Type: Task
Reporter: Avinash Dongre


All methods in an interface are implicitly {{public}} and {{abstract}}
All fields in an interface are implicitly {{public}}, {{static}} and {{final}}.

We have almost in all the interface public modifier for all the methods in the 
Interfaces, we should remove the same.



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

[jira] [Commented] (GEODE-240) Remove deprecated methods on TransactionEvent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-240:
--

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/515
  
+1 LGTM


> Remove deprecated methods on TransactionEvent
> -
>
> Key: GEODE-240
> URL: https://issues.apache.org/jira/browse/GEODE-240
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The following methods should all be deleted from TransactionEvent and callers 
> should be changed to instead use getEvents. The caller may have to do its own 
> filtering on getEvents to find the event(s) it is interested in.
> - getCreateEvents
> - getDestroyEvents
> - getPutEvents
> - getInvalidateEvents
> Some of the existing unit tests depend on the filtering done by these methods 
> so that filtering will need to move to some test util methods.



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

[GitHub] geode issue #515: GEODE-240: Remove deprecated methods on TransactionEvent

[davinash]

Github user davinash commented on the issue:

https://github.com/apache/geode/pull/515
  
+1 LGTM


---
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 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Jinmei Liao]

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




geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
Line 98 (original), 104 (patched)


once all your commands extends this abstract class, these don't need to be 
static at all. I would keep them as object methods.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
Line 120 (original), 126 (patched)


same here



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
Lines 46 (patched)


I believe all these new commands needs to extends AbstractCommandSupport 
which implements CommandMarker. The parser scans this interface implementers to 
do parsing work.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
Lines 43 (patched)


extend the abstract class



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
Lines 36 (patched)


extend the abstract class



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
Lines 42 (patched)


you can extends AbstractCommandSupport to get the method you need.



geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
Lines 40 (patched)


extend the abstract class


- Jinmei Liao


On May 23, 2017, 9:54 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59492/
> ---
> 
> (Updated May 23, 2017, 9:54 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Extract several commands out of LauncherLifecycleCommands into their 
> distinct own classes.
>  - Extract some utility methods from LauncherLifecycleCommands into more 
> appropriate locations.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  27bc098 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
>  2a1662e 
>   geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
> ce66057 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 12c5c21 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> a6d3064 
>   
> geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
>  18fca98 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
>  26b903b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  b6c11c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/MXBeanProvider.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/H

Re: Issues due to Special exceptions in RVV

[Darrel Schneider]

Yes, please file a jira and share your fix.

We are wondering if in delta GII it would just cause some extra entries to
be sent.
In that case it will just impact performance but not data consistency.

What kind of issues are you seeing?

On Tue, May 23, 2017 at 11:54 AM, Suranjan Kumar 
wrote:

> Hi Darrel,
>   Actually, I reproduced the issue in unit test that was seen in one of the
> runs and initializeVersionHolder doesn't fix the issue.
>   The initializeFrom is used to initialize a member's RVV from a  GII
> provider.
>
>   It turns out if a member has already recorded higher version then while
> initializing a version holder from a member with lower version, we
> introduce an special exception.
>   But in future when new versions are recorded by the same member, the
> special exception is not handled properly and that leads to version holder
> data structure corruption leading to holder#contains(version) error. In
> fact, I see that in this case an exception can remain permanently in the
> version holder even though the version has been recorded.
>
>   I have a fix, which I will send for review soon. However, I just wanted
> to understand the issue and why it is not caught in delta GII.
>
>  Moreover, if you look at the method initializeFrom, then already recorded
> versions are ignored? Isn't that an issue? If not then why?
>  I will file a JIRA if you suggest.
>
> On Tue, May 23, 2017 at 10:49 PM, Darrel Schneider 
> wrote:
>
> > I see that this test directly calls initializeFrom but the product never
> > does this.
> > The product always calls it through this method:
> >
> > org.apache.geode.internal.cache.versions.RegionVersionVector.
> > initializeVersionHolder(T,
> > RegionVersionHolder)
> >
> > I can see that initializeVersionHolder checks a memberToVersion map and
> on
> > a miss does not call initializeFrom but instead add the new member's RVV
> to
> > the memberToVersion map. Have you considered if calling
> > initializeVersionHolder would fix the issues you are seeing?
> >
> >
> > On Tue, May 23, 2017 at 10:04 AM, Darrel Schneider <
> dschnei...@pivotal.io>
> > wrote:
> >
> > > I made these modifications and the following compiles, runs, and fails
> on
> > > geode.
> > > I added the following to RegionVersionVectorJUnitTest:
> > >   @Test
> > >   public void testInitialized() {
> > >
> > > RegionVersionHolder vh1 = new RegionVersionHolder<>("vh1");
> > > vh1.recordVersion(56);
> > > vh1.recordVersion(57);
> > > vh1.recordVersion(58);
> > > vh1.recordVersion(59);
> > > vh1.recordVersion(60);
> > > assertTrue(vh1.contains(57));
> > > vh1 = vh1.clone();
> > > assertTrue(vh1.contains(57));
> > > System.out.println("This node init, vh1="+vh1);
> > >
> > > RegionVersionHolder vh2 = new RegionVersionHolder<>("vh2");
> > > for(int i=1;i<57;i++) {
> > >   vh2.recordVersion(i);
> > > }
> > > vh2 = vh2.clone();
> > > System.out.println("GII node init, vh2="+vh2);
> > >
> > > vh1.initializeFrom(vh2);
> > > // assertTrue(vh1.contains(57)); // fails
> > > vh1 = vh1.clone();
> > > System.out.println("After initialize, vh1="+vh1);
> > >
> > > vh1.recordVersion(58);
> > > vh1.recordVersion(59);
> > > vh1.recordVersion(60);
> > >
> > > System.out.println("After initialize and record version,
> vh1="+vh1);
> > >
> > > vh1 = vh1.clone();
> > > vh1.recordVersion(57);
> > > System.out.println("After initialize and record version after
> clone,
> > > vh1="+vh1);
> > >
> > > assertTrue(vh1.contains(57)); //FAILS
> > >   }
> > >
> > >
> > > On Tue, May 23, 2017 at 9:37 AM, Kirk Lund  wrote:
> > >
> > >> Are you sure you're using Geode? The signature of
> > >> RegionVersionHolder#recordVersion
> > >> in Geode is:
> > >>
> > >> RegionVersionHolder#recordVersion(long)
> > >>
> > >> I recommend checking out develop branch of Geode, write a test to
> > confirm
> > >> your bug and then submit that test with a Jira ticket.
> > >>
> > >> On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar <
> > suranjan.ku...@gmail.com
> > >> >
> > >> wrote:
> > >>
> > >> > Hi Bruce/Dan,
> > >> >
> > >> >  #1. I see some issues due to introduction of special exceptions in
> > the
> > >> > RegionVersionHolder. In some cases, it is leading to
> > RegionVersionHolder
> > >> > data structure corruption causing wrong contains(version) results.
> > >> >
> > >> >  This happens because we set the version to max of currentVersion or
> > >> newly
> > >> > recorded one. But do not try to fix the special exception present if
> > >> any.
> > >> >
> > >> >  It is easily reproducible even in junit tests.
> > >> > The corruption of holder data stricture causes even future record
> > >> operation
> > >> > to fail.
> > >> > For example the following test fails:
> > >> >
> > >> >  public void testInitialized() {
> > >> >
> > >> >   RegionVersionHolder vh1 = new RegionVersionHolder(member);
> > >> >   vh1.recordVersion(56, null);
> > >> >   vh1.recordV

Re: Review Request 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Jinmei Liao]

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




geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/ClusterConfiguration.java
Lines 30 (patched)


This is more like a ClusterConfigurationStatusUtil class.


- Jinmei Liao


On May 23, 2017, 9:54 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59492/
> ---
> 
> (Updated May 23, 2017, 9:54 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Extract several commands out of LauncherLifecycleCommands into their 
> distinct own classes.
>  - Extract some utility methods from LauncherLifecycleCommands into more 
> appropriate locations.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  27bc098 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
>  2a1662e 
>   geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
> ce66057 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 12c5c21 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> a6d3064 
>   
> geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
>  18fca98 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
>  26b903b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  b6c11c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/MXBeanProvider.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/HostUtils.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/JdkTool.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/ClusterConfiguration.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommandTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/HostUtilsTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/JdkToolTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59492/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2580:


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

GEODE-2580 : Pre Kotlin conversion


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



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

[jira] [Commented] (GEODE-2964) NPE on gfsh put command

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2964:


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

GEODE-2964: add common-collections to gfsh dependencies


> NPE on gfsh put command
> ---
>
> Key: GEODE-2964
> URL: https://issues.apache.org/jira/browse/GEODE-2964
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>
> After seeing up one locator one server, I created a partitioned region and 
> try to put a value in it from gfsh which resulted in a NPE:
> {noformat}
> gfsh>start locator --name=loc1
> gfsh>start server --name=serv1
> gfsh>create region --name=foo --type=PARTITION
> gfsh>put --key=1 --value=one --region=/foo
> 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 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
>   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.rmi.server.UnicastServerR

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2580:


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

GEODE-2580 : Post Kotlin changes


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



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

[jira] [Updated] (GEODE-2966) Refactor LauncherLifecycleCommands

[Jared Stewart (JIRA)]

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

Jared Stewart updated GEODE-2966:
-
Description: LauncherLifecycleCommands is over 2000 lines of code, and 
could be made a lot more readable by introducing proper OO abstraction.  There 
are also many private static final strings like 
{{CliStrings.START_LOCATOR__MEMBER_NAME}} that could be made shorter and more 
contextual, e.g. {{StartLocatorCommand.MEMBER_NAME}}.  (was: 
LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
more readable by introducing proper OO abstraction.  There are also many 
private static final strings like `CliStrings.START_LOCATOR__MEMBER_NAME` that 
could be made shorter and more contextual, e.g. 
`StartLocatorCommand.MEMBER_NAME`.)

> Refactor LauncherLifecycleCommands
> --
>
> Key: GEODE-2966
> URL: https://issues.apache.org/jira/browse/GEODE-2966
> Project: Geode
>  Issue Type: Sub-task
>  Components: gfsh, management
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>
> LauncherLifecycleCommands is over 2000 lines of code, and could be made a lot 
> more readable by introducing proper OO abstraction.  There are also many 
> private static final strings like {{CliStrings.START_LOCATOR__MEMBER_NAME}} 
> that could be made shorter and more contextual, e.g. 
> {{StartLocatorCommand.MEMBER_NAME}}.



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

[jira] [Resolved] (GEODE-2918) ConflictingPersistentDataException is not handled properly

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade resolved GEODE-2918.
--
   Resolution: Fixed
Fix Version/s: 1.2.0

> ConflictingPersistentDataException is not handled properly
> --
>
> Key: GEODE-2918
> URL: https://issues.apache.org/jira/browse/GEODE-2918
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> During disk recovery the ConflictingPersistentDataException is not handled 
> properly; it should have logged an error and closed the cache.
> When it is handled incorrectly, the cache is in inconsistent state; causing 
> other operations to fail in unexpected ways.



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

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

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-2952:
--

Assignee: David Anuta

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



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

[jira] [Assigned] (GEODE-2918) ConflictingPersistentDataException is not handled properly

[Anilkumar Gingade (JIRA)]

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

Anilkumar Gingade reassigned GEODE-2918:


Assignee: Anilkumar Gingade

> ConflictingPersistentDataException is not handled properly
> --
>
> Key: GEODE-2918
> URL: https://issues.apache.org/jira/browse/GEODE-2918
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Anilkumar Gingade
>Assignee: Anilkumar Gingade
>  Labels: storage_2
> Fix For: 1.2.0
>
>
> During disk recovery the ConflictingPersistentDataException is not handled 
> properly; it should have logged an error and closed the cache.
> When it is handled incorrectly, the cache is in inconsistent state; causing 
> other operations to fail in unexpected ways.



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

[jira] [Commented] (GEODE-2979) Adding server after defining Lucene index results in unusable cluster

[Diane Hardman (JIRA)]

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

Diane Hardman commented on GEODE-2979:
--

Please ignore the NPE after the put command. This was a known issue 
(GEODE-2964) that I stumbled across.

> Adding server after defining Lucene index results in unusable cluster
> -
>
> Key: GEODE-2979
> URL: https://issues.apache.org/jira/browse/GEODE-2979
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>
> 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 
> com.sun.jmx.mbeanserver.ConvertingMethod

Re: Review Request 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On May 23, 2017, 9:54 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59492/
> ---
> 
> (Updated May 23, 2017, 9:54 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Extract several commands out of LauncherLifecycleCommands into their 
> distinct own classes.
>  - Extract some utility methods from LauncherLifecycleCommands into more 
> appropriate locations.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  27bc098 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
>  2a1662e 
>   geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
> ce66057 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 12c5c21 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> a6d3064 
>   
> geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
>  18fca98 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
>  26b903b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  b6c11c4 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/MXBeanProvider.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/HostUtils.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/JdkTool.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/ClusterConfiguration.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommandTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/HostUtilsTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/JdkToolTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59492/diff/2/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

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

[Spring CI]

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

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





--
This message is automatically generated by Atlassian Bamboo

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2967:


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

GEODE-2967: ResultCollection instead of StructCollection

* If we have one runtime iterator which is in case of self joins, 
ResultSet or ResultBags are created
* Otherwise StructBag or StructSets are used


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



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

[jira] [Commented] (GEODE-2961) Distinct query with an or condition may miss results

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2961:


Commit 456ee15768fb08c8e1c8c5836479d27e1bc61835 in geode's branch 
refs/heads/feature/GEODE-2632-17 from [~DivineEnder]
[ https://git-wip-us.apache.org/repos/asf?p=geode.git;h=456ee15 ]

GEODE-2961: Fixed distinct multiple OR query returning partial results


> Distinct query with an or condition may miss results
> 
>
> Key: GEODE-2961
> URL: https://issues.apache.org/jira/browse/GEODE-2961
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> Sample query where this may be an issue:
> "select id from /region where r.status in set('active') or r.name in 
> set('joe')"
> The results will contain only one of the predicates.
> The issue might be:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults = filterResults;
> {noformat}
> but it should probably read as:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults.addAll(filterResults);
> {noformat}



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

Re: Review Request 59404: GEODE-2939: make sure event tracker is initiated from the GII provider

[Eric Shu]

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

(Updated May 23, 2017, 10:32 p.m.)


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


Changes
---

fix review comments


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


Repository: geode


Description
---

Event tracker initilization for bucket region is delayed until after GII, and 
will be initialized from the GII provider.


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
886d678 
  
geode-core/src/main/java/org/apache/geode/internal/cache/CacheDistributionAdvisee.java
 e4a7957 
  
geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
 c1d1e77 
  
geode-core/src/main/java/org/apache/geode/internal/cache/DistributedRegion.java 
485835b 
  geode-core/src/main/java/org/apache/geode/internal/cache/EventTracker.java 
2c86aed 
  
geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
 fb5f0cf 
  
geode-core/src/test/java/org/apache/geode/internal/cache/EventTrackerDUnitTest.java
 3faf41f 


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

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


Testing
---

precheckin.


Thanks,

Eric Shu

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[ASF GitHub Bot (JIRA)]

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

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

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode/pull/518
  
Commit 
https://github.com/apache/geode/pull/518/commits/012983e58311572d155835a95d8a51a784bf1283
 adds reference information about the XSD (xml) definitions for Lucene indexes. 
 Can all devs with knowledge of the Lucene implementation do a review of this 
commit?  The Geode devs I know about that would be good reviewers: @ladyVader 
@upthewaterspout @nabarunnag @jhuynh1 @dihardman @DivineEnder @boglesby 



> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes require

[GitHub] geode issue #518: GEODE-2913 Update Lucene index documentation

[karensmolermiller]

Github user karensmolermiller commented on the issue:

https://github.com/apache/geode/pull/518
  
Commit 
https://github.com/apache/geode/pull/518/commits/012983e58311572d155835a95d8a51a784bf1283
 adds reference information about the XSD (xml) definitions for Lucene indexes. 
 Can all devs with knowledge of the Lucene implementation do a review of this 
commit?  The Geode devs I know about that would be good reviewers: @ladyVader 
@upthewaterspout @nabarunnag @jhuynh1 @dihardman @DivineEnder @boglesby 



---
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-1994) Change geode StringUtils to extend commons StringUtils

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/528
  
Precheckin running...


> Change geode StringUtils to extend commons StringUtils
> --
>
> Key: GEODE-1994
> URL: https://issues.apache.org/jira/browse/GEODE-1994
> Project: Geode
>  Issue Type: Wish
>  Components: general, management
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>
> org.apache.geode.internal.lang.StringUtils duplicates some of the methods in 
> org.apache.commons.lang.StringUtils with some inconsistencies.
> isBlank is implemented identically
> isEmpty is inconsistent -- commons version returns true if string is null, 
> while geode version returns false if string is null



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

[GitHub] geode issue #528: GEODE-1994, revisited: Removed guaranteed failures.

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/528
  
Precheckin running...


---
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-1994) Change geode StringUtils to extend commons StringUtils

[ASF GitHub Bot (JIRA)]

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

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

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/528
  
LGTM (pending green precheckin)


> Change geode StringUtils to extend commons StringUtils
> --
>
> Key: GEODE-1994
> URL: https://issues.apache.org/jira/browse/GEODE-1994
> Project: Geode
>  Issue Type: Wish
>  Components: general, management
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>
> org.apache.geode.internal.lang.StringUtils duplicates some of the methods in 
> org.apache.commons.lang.StringUtils with some inconsistencies.
> isBlank is implemented identically
> isEmpty is inconsistent -- commons version returns true if string is null, 
> while geode version returns false if string is null



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

[GitHub] geode issue #528: GEODE-1994, revisited: Removed guaranteed failures.

[jaredjstewart]

Github user jaredjstewart commented on the issue:

https://github.com/apache/geode/pull/528
  
LGTM (pending green precheckin)


---
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 59505: GEODE-2964: add common-collections to gfsh dependencies

[Ken Howe]

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


Ship it!




Ship It!

- Ken Howe


On May 23, 2017, 10:11 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59505/
> ---
> 
> (Updated May 23, 2017, 10:11 p.m.)
> 
> 
> Review request for geode, Jared Stewart, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2964: add common-collections to gfsh dependencies
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle a4f0c69ee39342d9a3350d8e3a32cd65b560c75a 
> 
> 
> Diff: https://reviews.apache.org/r/59505/diff/1/
> 
> 
> Testing
> ---
> 
> gfsh manual tests
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

[GitHub] geode issue #523: GEODE-2967: ResultCollection instead of StructCollection

[nabarunnag]

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/523
  
@DivineEnder



---
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-2967) Internal Errors thrown while executing queries involving self join

[ASF GitHub Bot (JIRA)]

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

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

Github user nabarunnag commented on the issue:

https://github.com/apache/geode/pull/523
  
@DivineEnder



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



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

[jira] [Updated] (GEODE-2979) Adding server after defining Lucene index results in unusable cluster

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-2979:
-
Description: 
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 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanS

Re: Review Request 59505: GEODE-2964: add common-collections to gfsh dependencies

[Jinmei Liao]

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

(Updated May 23, 2017, 10:11 p.m.)


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


Repository: geode


Description
---

GEODE-2964: add common-collections to gfsh dependencies


Diffs
-

  geode-assembly/build.gradle a4f0c69ee39342d9a3350d8e3a32cd65b560c75a 


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


Testing
---

gfsh manual tests


Thanks,

Jinmei Liao

[GitHub] geode pull request #528: GEODE-1994, revisited: Removed guaranteed failures.

[PurelyApplied]

GitHub user PurelyApplied opened a pull request:

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

GEODE-1994, revisited: Removed guaranteed failures.

Removed two uses of ServerLauncher.Builder.setMemberName that are 
guaranteed to throw under the changes introduced by GEODE-1994.

With the previous update to StringUtils, 
ServerLauncher.Builder.setMemberName throws when its input is blank.  These two 
uses are behind conditionals and only occur when the member name is blank, 
guaranteeing failure.  This results in the `status server` and `stop server` 
commands functioning only when `--name` is used, but failing with `--dir` and 
`--pid`.

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

$ git pull https://github.com/PurelyApplied/geode geode-1994.revised

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

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


commit 071780ed1aa2b12068f12291d032c30a930320ac
Author: Patrick Rhomberg 
Date:   2017-05-23T22:07:11Z

GEODE-1994, revisited: Removed two references to 
ServerLauncher.setMemberName that are guaranteed to throw under the changes 
introduced by GEODE-1994.




---
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-1994) Change geode StringUtils to extend commons StringUtils

[ASF GitHub Bot (JIRA)]

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

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

GitHub user PurelyApplied opened a pull request:

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

GEODE-1994, revisited: Removed guaranteed failures.

Removed two uses of ServerLauncher.Builder.setMemberName that are 
guaranteed to throw under the changes introduced by GEODE-1994.

With the previous update to StringUtils, 
ServerLauncher.Builder.setMemberName throws when its input is blank.  These two 
uses are behind conditionals and only occur when the member name is blank, 
guaranteeing failure.  This results in the `status server` and `stop server` 
commands functioning only when `--name` is used, but failing with `--dir` and 
`--pid`.

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

$ git pull https://github.com/PurelyApplied/geode geode-1994.revised

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

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


commit 071780ed1aa2b12068f12291d032c30a930320ac
Author: Patrick Rhomberg 
Date:   2017-05-23T22:07:11Z

GEODE-1994, revisited: Removed two references to 
ServerLauncher.setMemberName that are guaranteed to throw under the changes 
introduced by GEODE-1994.




> Change geode StringUtils to extend commons StringUtils
> --
>
> Key: GEODE-1994
> URL: https://issues.apache.org/jira/browse/GEODE-1994
> Project: Geode
>  Issue Type: Wish
>  Components: general, management
>Reporter: Kirk Lund
>Assignee: Patrick Rhomberg
>
> org.apache.geode.internal.lang.StringUtils duplicates some of the methods in 
> org.apache.commons.lang.StringUtils with some inconsistencies.
> isBlank is implemented identically
> isEmpty is inconsistent -- commons version returns true if string is null, 
> while geode version returns false if string is null



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

[jira] [Resolved] (GEODE-2373) Fix Security quickstarts on Linux

[Ernest Burghardt (JIRA)]

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

Ernest Burghardt resolved GEODE-2373.
-
Resolution: Invalid

This is no longer needed.

> Fix Security quickstarts on Linux
> -
>
> Key: GEODE-2373
> URL: https://issues.apache.org/jira/browse/GEODE-2373
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Ernest Burghardt
>
> missing Install configuration for Linux in Cmake file 



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

[jira] [Commented] (GEODE-2975) Attributes are not validated in lucene xml configuration

[Dan Smith (JIRA)]

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

Dan Smith commented on GEODE-2975:
--

I did a quick experiment. It looks like we would do validation, except we are 
not actually finding the lucene schema.

All of the xml examples I find say that the lucene schema location should be 
this :http://geode.apache.org/schema/lucene/lucene-1.0.xsd

However, that url does not actually resolve the lucene schema. I found a copy 
of that schema here,  but this seems incorrect: 
http://geode.apache.org/schema/cache/lucene-1.0.xsd

So first off, We should update the website to put the schema in the correct 
location.

However we have an optimization to avoid downloading the xsd from the website 
every time. We use the GeodeEntityResolver to read the xsds from the classpath 
instead. Unfortunately, it looks like the XSD is also in the wrong location in 
our source tree. The GeodeEntityResolver is going to look for the file in 
/META-INF/schemas/geode.apache.org/schema/lucene/lucene-1.0.xsd. But the lucene 
schema is in  /META-INF/schemas/geode.apache.org/lucene/lucene-1.0.xsd. So we 
need to fix the location of the xsd in the source checkout.

If we fix either of these things, then the validation should work as expected.
Unfortunately, the 

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



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

Re: Review Request 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Jared Stewart]

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

(Updated May 23, 2017, 9:54 p.m.)


Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Changes
---

Extract methods to get at MXBeans into their own class.  Rename 
SharedConfiguration -> ClusterConfiguration.


Repository: geode


Description
---

- Extract several commands out of LauncherLifecycleCommands into their distinct 
own classes.
 - Extract some utility methods from LauncherLifecycleCommands into more 
appropriate locations.


Diffs (updated)
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
 27bc098 
  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
 2a1662e 
  geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
ce66057 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
12c5c21 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
a6d3064 
  
geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
 18fca98 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
 26b903b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 b6c11c4 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 68d055c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/shell/MXBeanProvider.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/HostUtils.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/JdkTool.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/ClusterConfiguration.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommandTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/HostUtilsTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/JdkToolTest.java
 PRE-CREATION 


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

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


Testing
---

Precheckin running


Thanks,

Jared Stewart

[jira] [Resolved] (GEODE-2509) Build failed at openSUSE LEAP 42.2

[Ernest Burghardt (JIRA)]

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

Ernest Burghardt resolved GEODE-2509.
-
Resolution: Fixed

PR 47

> Build failed at openSUSE LEAP 42.2
> --
>
> Key: GEODE-2509
> URL: https://issues.apache.org/jira/browse/GEODE-2509
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Reporter: Danilo Chang
>Priority: Minor
> Attachments: fix_build_opensuse.patch
>
>
> geode-native C++ client build failed at openSUSE LEAP 42.2, because the 
> library folder name is different at 32bit or 64bit environment (lib64 at 
> 64bit environment and lib at 32bit environment). Now 2 components has this 
> issue, libxml2 and xerces-c.
> The attachment file is the solution I try to fix this issue (use --libdir to 
> specify the path). However, I don't know Geode native C++ client prefer to 
> use the same lib folder name or not. So I create this JIRA item.



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

[jira] [Updated] (GEODE-2979) Adding server after defining Lucene index results in unusable cluster

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-2979:
-
Description: 
Here are the gfsh commands I used:
```
## 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 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
at 
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at 
com.sun.jmx.mbeanserver.JmxMBeanServer.i

[jira] [Updated] (GEODE-2979) Adding server after defining Lucene index results in unusable cluster

[Diane Hardman (JIRA)]

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

Diane Hardman updated GEODE-2979:
-
Summary: Adding server after defining Lucene index results in unusable 
cluster  (was: Adding server after creating Lucene index results in unusable 
cluster)

> Adding server after defining Lucene index results in unusable cluster
> -
>
> Key: GEODE-2979
> URL: https://issues.apache.org/jira/browse/GEODE-2979
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Diane Hardman
>
> Here are the gfsh commands I used:
> ## 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 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpe

[jira] [Commented] (GEODE-2741) Use C++11 shared pointer over custom shared pointer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2741:


Commit d1710133a12ba674648fd33e7eb04f1f2dce93b7 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=d171013 ]

GEODE-2741: Adds .NET 3.5 runtime for NUnit tests.


> Use C++11 shared pointer over custom shared pointer
> ---
>
> Key: GEODE-2741
> URL: https://issues.apache.org/jira/browse/GEODE-2741
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Addison
>Assignee: Jacob S. Barrett
>
> *Context*
> Now that the Native Client is compatible with C++11, we can use its shared 
> pointer over the custom shared pointer we use today.
> *Definition of Done*
> The custom shared pointer is nowhere to be found in the codebase



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

[jira] [Created] (GEODE-2979) Adding server after creating Lucene index results in unusable cluster

[Diane Hardman (JIRA)]

Diane Hardman created GEODE-2979:


 Summary: Adding server after creating Lucene index results in 
unusable cluster
 Key: GEODE-2979
 URL: https://issues.apache.org/jira/browse/GEODE-2979
 Project: Geode
  Issue Type: Bug
  Components: lucene
Reporter: Diane Hardman


Here are the gfsh commands I used:
## 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 
com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
at 
com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
at 
com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.jav

[jira] [Created] (GEODE-2978) Add feature toggle for new protocol & merge into develop

[Brian Baynes (JIRA)]

Brian Baynes created GEODE-2978:
---

 Summary: Add feature toggle for new protocol & merge into develop
 Key: GEODE-2978
 URL: https://issues.apache.org/jira/browse/GEODE-2978
 Project: Geode
  Issue Type: Sub-task
  Components: client/server
Reporter: Brian Baynes


Add a feature toggle for new protocol so we can merge into develop and simplify 
collaboration.

Final deliverable:  new protocol code under feature toggle on develop.



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

[jira] [Assigned] (GEODE-2955) gfsh create lucene index command should validate the region name parameter

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-2955:
--

Assignee: David Anuta

> gfsh create lucene index command should validate the region name parameter
> --
>
> Key: GEODE-2955
> URL: https://issues.apache.org/jira/browse/GEODE-2955
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> The gfsh command to create the lucene index should not only validate the 
> lucene index name but also the region name.  It currently is possible to pass 
> an invalid region name as a parameter.  The region will then not be able to 
> be created.



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

[jira] [Commented] (GEODE-2961) Distinct query with an or condition may miss results

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2961:


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

GEODE-2961: Fixed distinct multiple OR query returning partial results


> Distinct query with an or condition may miss results
> 
>
> Key: GEODE-2961
> URL: https://issues.apache.org/jira/browse/GEODE-2961
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> Sample query where this may be an issue:
> "select id from /region where r.status in set('active') or r.name in 
> set('joe')"
> The results will contain only one of the predicates.
> The issue might be:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults = filterResults;
> {noformat}
> but it should probably read as:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults.addAll(filterResults);
> {noformat}



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

[jira] [Commented] (GEODE-2961) Distinct query with an or condition may miss results

[ASF GitHub Bot (JIRA)]

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

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

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/527
  
@nabarunnag @upthewaterspout @jhuynh1 @ladyVader @boglesby 


> Distinct query with an or condition may miss results
> 
>
> Key: GEODE-2961
> URL: https://issues.apache.org/jira/browse/GEODE-2961
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> Sample query where this may be an issue:
> "select id from /region where r.status in set('active') or r.name in 
> set('joe')"
> The results will contain only one of the predicates.
> The issue might be:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults = filterResults;
> {noformat}
> but it should probably read as:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults.addAll(filterResults);
> {noformat}



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

[GitHub] geode issue #527: GEODE-2961: Fixed distinct multiple OR query returning par...

[DivineEnder]

Github user DivineEnder commented on the issue:

https://github.com/apache/geode/pull/527
  
@nabarunnag @upthewaterspout @jhuynh1 @ladyVader @boglesby 


---
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-2961) Distinct query with an or condition may miss results

[ASF GitHub Bot (JIRA)]

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

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

GitHub user DivineEnder opened a pull request:

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

GEODE-2961: Fixed distinct multiple OR query returning partial results

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/DivineEnder/geode feature/GEODE-2961

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

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


commit 8f77fc2ad87fbc7b7b565005f120ab0ae822aca7
Author: David Anuta 
Date:   2017-05-23T20:53:19Z

GEODE-2961: Fixed distinct multiple OR query returning partial results




> Distinct query with an or condition may miss results
> 
>
> Key: GEODE-2961
> URL: https://issues.apache.org/jira/browse/GEODE-2961
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> Sample query where this may be an issue:
> "select id from /region where r.status in set('active') or r.name in 
> set('joe')"
> The results will contain only one of the predicates.
> The issue might be:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults = filterResults;
> {noformat}
> but it should probably read as:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults.addAll(filterResults);
> {noformat}



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

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

[ASF GitHub Bot (JIRA)]

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

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

Github user nabarunnag closed the pull request at:

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


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



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

[GitHub] geode pull request #523: GEODE-2967: ResultCollection instead of StructColle...

[nabarunnag]

Github user nabarunnag closed the pull request at:

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


---
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 #527: GEODE-2961: Fixed distinct multiple OR query return...

[DivineEnder]

GitHub user DivineEnder opened a pull request:

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

GEODE-2961: Fixed distinct multiple OR query returning partial results

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/DivineEnder/geode feature/GEODE-2961

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

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


commit 8f77fc2ad87fbc7b7b565005f120ab0ae822aca7
Author: David Anuta 
Date:   2017-05-23T20:53:19Z

GEODE-2961: Fixed distinct multiple OR query returning partial results




---
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-2967) Internal Errors thrown while executing queries involving self join

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2967:


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

GEODE-2967: ResultCollection instead of StructCollection

* If we have one runtime iterator which is in case of self joins, 
ResultSet or ResultBags are created
* Otherwise StructBag or StructSets are used


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



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

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

[Karen Smoler Miller (JIRA)]

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

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

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



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

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

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2951:


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

GEODE-2951: Removed --pageSize option


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



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

Re: Issues due to Special exceptions in RVV

[Anilkumar Gingade]

Suranjan,

In your run, are you seeing GII failing on one server and then continuing
from another server?

Say there are 3 nodes in cluster. node1 and node2 with region r1
(exists)
- r1 is created on node3.
- node3 starts gii from node1 (gets disconnected in between).
- node3 starts gii from node2.

-Anil.










On Tue, May 23, 2017 at 11:54 AM, Suranjan Kumar 
wrote:

> Hi Darrel,
>   Actually, I reproduced the issue in unit test that was seen in one of the
> runs and initializeVersionHolder doesn't fix the issue.
>   The initializeFrom is used to initialize a member's RVV from a  GII
> provider.
>
>   It turns out if a member has already recorded higher version then while
> initializing a version holder from a member with lower version, we
> introduce an special exception.
>   But in future when new versions are recorded by the same member, the
> special exception is not handled properly and that leads to version holder
> data structure corruption leading to holder#contains(version) error. In
> fact, I see that in this case an exception can remain permanently in the
> version holder even though the version has been recorded.
>
>   I have a fix, which I will send for review soon. However, I just wanted
> to understand the issue and why it is not caught in delta GII.
>
>  Moreover, if you look at the method initializeFrom, then already recorded
> versions are ignored? Isn't that an issue? If not then why?
>  I will file a JIRA if you suggest.
>
> On Tue, May 23, 2017 at 10:49 PM, Darrel Schneider 
> wrote:
>
> > I see that this test directly calls initializeFrom but the product never
> > does this.
> > The product always calls it through this method:
> >
> > org.apache.geode.internal.cache.versions.RegionVersionVector.
> > initializeVersionHolder(T,
> > RegionVersionHolder)
> >
> > I can see that initializeVersionHolder checks a memberToVersion map and
> on
> > a miss does not call initializeFrom but instead add the new member's RVV
> to
> > the memberToVersion map. Have you considered if calling
> > initializeVersionHolder would fix the issues you are seeing?
> >
> >
> > On Tue, May 23, 2017 at 10:04 AM, Darrel Schneider <
> dschnei...@pivotal.io>
> > wrote:
> >
> > > I made these modifications and the following compiles, runs, and fails
> on
> > > geode.
> > > I added the following to RegionVersionVectorJUnitTest:
> > >   @Test
> > >   public void testInitialized() {
> > >
> > > RegionVersionHolder vh1 = new RegionVersionHolder<>("vh1");
> > > vh1.recordVersion(56);
> > > vh1.recordVersion(57);
> > > vh1.recordVersion(58);
> > > vh1.recordVersion(59);
> > > vh1.recordVersion(60);
> > > assertTrue(vh1.contains(57));
> > > vh1 = vh1.clone();
> > > assertTrue(vh1.contains(57));
> > > System.out.println("This node init, vh1="+vh1);
> > >
> > > RegionVersionHolder vh2 = new RegionVersionHolder<>("vh2");
> > > for(int i=1;i<57;i++) {
> > >   vh2.recordVersion(i);
> > > }
> > > vh2 = vh2.clone();
> > > System.out.println("GII node init, vh2="+vh2);
> > >
> > > vh1.initializeFrom(vh2);
> > > // assertTrue(vh1.contains(57)); // fails
> > > vh1 = vh1.clone();
> > > System.out.println("After initialize, vh1="+vh1);
> > >
> > > vh1.recordVersion(58);
> > > vh1.recordVersion(59);
> > > vh1.recordVersion(60);
> > >
> > > System.out.println("After initialize and record version,
> vh1="+vh1);
> > >
> > > vh1 = vh1.clone();
> > > vh1.recordVersion(57);
> > > System.out.println("After initialize and record version after
> clone,
> > > vh1="+vh1);
> > >
> > > assertTrue(vh1.contains(57)); //FAILS
> > >   }
> > >
> > >
> > > On Tue, May 23, 2017 at 9:37 AM, Kirk Lund  wrote:
> > >
> > >> Are you sure you're using Geode? The signature of
> > >> RegionVersionHolder#recordVersion
> > >> in Geode is:
> > >>
> > >> RegionVersionHolder#recordVersion(long)
> > >>
> > >> I recommend checking out develop branch of Geode, write a test to
> > confirm
> > >> your bug and then submit that test with a Jira ticket.
> > >>
> > >> On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar <
> > suranjan.ku...@gmail.com
> > >> >
> > >> wrote:
> > >>
> > >> > Hi Bruce/Dan,
> > >> >
> > >> >  #1. I see some issues due to introduction of special exceptions in
> > the
> > >> > RegionVersionHolder. In some cases, it is leading to
> > RegionVersionHolder
> > >> > data structure corruption causing wrong contains(version) results.
> > >> >
> > >> >  This happens because we set the version to max of currentVersion or
> > >> newly
> > >> > recorded one. But do not try to fix the special exception present if
> > >> any.
> > >> >
> > >> >  It is easily reproducible even in junit tests.
> > >> > The corruption of holder data stricture causes even future record
> > >> operation
> > >> > to fail.
> > >> > For example the following test fails:
> > >> >
> > >> >  public void testInitialized() {
> > >> >
> > >> >   RegionVersionHolder vh1 = new RegionV

[jira] [Assigned] (GEODE-2961) Distinct query with an or condition may miss results

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-2961:
--

Assignee: David Anuta

> Distinct query with an or condition may miss results
> 
>
> Key: GEODE-2961
> URL: https://issues.apache.org/jira/browse/GEODE-2961
> Project: Geode
>  Issue Type: Bug
>  Components: querying
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> Sample query where this may be an issue:
> "select id from /region where r.status in set('active') or r.name in 
> set('joe')"
> The results will contain only one of the predicates.
> The issue might be:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults = filterResults;
> {noformat}
> but it should probably read as:
> {noformat}
>  } else if (isDistinct && !isConditioningNeeded) {
>   intermediateResults.addAll(filterResults);
> {noformat}



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

Re: Issues due to Special exceptions in RVV

[Suranjan Kumar]

Hi Darrel,
  Actually, I reproduced the issue in unit test that was seen in one of the
runs and initializeVersionHolder doesn't fix the issue.
  The initializeFrom is used to initialize a member's RVV from a  GII
provider.

  It turns out if a member has already recorded higher version then while
initializing a version holder from a member with lower version, we
introduce an special exception.
  But in future when new versions are recorded by the same member, the
special exception is not handled properly and that leads to version holder
data structure corruption leading to holder#contains(version) error. In
fact, I see that in this case an exception can remain permanently in the
version holder even though the version has been recorded.

  I have a fix, which I will send for review soon. However, I just wanted
to understand the issue and why it is not caught in delta GII.

 Moreover, if you look at the method initializeFrom, then already recorded
versions are ignored? Isn't that an issue? If not then why?
 I will file a JIRA if you suggest.

On Tue, May 23, 2017 at 10:49 PM, Darrel Schneider 
wrote:

> I see that this test directly calls initializeFrom but the product never
> does this.
> The product always calls it through this method:
>
> org.apache.geode.internal.cache.versions.RegionVersionVector.
> initializeVersionHolder(T,
> RegionVersionHolder)
>
> I can see that initializeVersionHolder checks a memberToVersion map and on
> a miss does not call initializeFrom but instead add the new member's RVV to
> the memberToVersion map. Have you considered if calling
> initializeVersionHolder would fix the issues you are seeing?
>
>
> On Tue, May 23, 2017 at 10:04 AM, Darrel Schneider 
> wrote:
>
> > I made these modifications and the following compiles, runs, and fails on
> > geode.
> > I added the following to RegionVersionVectorJUnitTest:
> >   @Test
> >   public void testInitialized() {
> >
> > RegionVersionHolder vh1 = new RegionVersionHolder<>("vh1");
> > vh1.recordVersion(56);
> > vh1.recordVersion(57);
> > vh1.recordVersion(58);
> > vh1.recordVersion(59);
> > vh1.recordVersion(60);
> > assertTrue(vh1.contains(57));
> > vh1 = vh1.clone();
> > assertTrue(vh1.contains(57));
> > System.out.println("This node init, vh1="+vh1);
> >
> > RegionVersionHolder vh2 = new RegionVersionHolder<>("vh2");
> > for(int i=1;i<57;i++) {
> >   vh2.recordVersion(i);
> > }
> > vh2 = vh2.clone();
> > System.out.println("GII node init, vh2="+vh2);
> >
> > vh1.initializeFrom(vh2);
> > // assertTrue(vh1.contains(57)); // fails
> > vh1 = vh1.clone();
> > System.out.println("After initialize, vh1="+vh1);
> >
> > vh1.recordVersion(58);
> > vh1.recordVersion(59);
> > vh1.recordVersion(60);
> >
> > System.out.println("After initialize and record version, vh1="+vh1);
> >
> > vh1 = vh1.clone();
> > vh1.recordVersion(57);
> > System.out.println("After initialize and record version after clone,
> > vh1="+vh1);
> >
> > assertTrue(vh1.contains(57)); //FAILS
> >   }
> >
> >
> > On Tue, May 23, 2017 at 9:37 AM, Kirk Lund  wrote:
> >
> >> Are you sure you're using Geode? The signature of
> >> RegionVersionHolder#recordVersion
> >> in Geode is:
> >>
> >> RegionVersionHolder#recordVersion(long)
> >>
> >> I recommend checking out develop branch of Geode, write a test to
> confirm
> >> your bug and then submit that test with a Jira ticket.
> >>
> >> On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar <
> suranjan.ku...@gmail.com
> >> >
> >> wrote:
> >>
> >> > Hi Bruce/Dan,
> >> >
> >> >  #1. I see some issues due to introduction of special exceptions in
> the
> >> > RegionVersionHolder. In some cases, it is leading to
> RegionVersionHolder
> >> > data structure corruption causing wrong contains(version) results.
> >> >
> >> >  This happens because we set the version to max of currentVersion or
> >> newly
> >> > recorded one. But do not try to fix the special exception present if
> >> any.
> >> >
> >> >  It is easily reproducible even in junit tests.
> >> > The corruption of holder data stricture causes even future record
> >> operation
> >> > to fail.
> >> > For example the following test fails:
> >> >
> >> >  public void testInitialized() {
> >> >
> >> >   RegionVersionHolder vh1 = new RegionVersionHolder(member);
> >> >   vh1.recordVersion(56, null);
> >> >   vh1.recordVersion(57, null);
> >> >   vh1.recordVersion(58, null);
> >> >   vh1.recordVersion(59, null);
> >> >   vh1.recordVersion(60, null);
> >> >   vh1 = vh1.clone();
> >> >   System.out.println("This node init, vh1="+vh1);
> >> >
> >> >   RegionVersionHolder vh2 = new RegionVersionHolder(member);
> >> >   for(int i=1;i<57;i++) {
> >> > vh2.recordVersion(i,null);
> >> >   }
> >> >   vh2 = vh2.clone();
> >> >   System.out.println("GII node init, vh2="+vh2);
> >> >
> >> >   vh1.initializeFrom(vh2);
> >> >   vh1 = vh1.clone();
> >> >   System.out.println("After initialize, vh1="+v

[jira] [Resolved] (GEODE-2943) Invalid queryStrings cause lucene searches to hang in in PR with multiple nodes

[Barry Oglesby (JIRA)]

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

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

> Invalid queryStrings cause lucene searches to hang in in PR with multiple 
> nodes
> ---
>
> Key: GEODE-2943
> URL: https://issues.apache.org/jira/browse/GEODE-2943
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
> Fix For: 1.2.0
>
>
> Some invalid query strings might be "*" or " ".
> When used with a single node dataStore, we see the correct Exception returned:
> {noformat}
> gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
> --defaultField=__REGION_VALUE_FIELD
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: Leading wildcard is not 
> allowed: __REGION_VALUE_FIELD:*
> {noformat}
> However, with multiple nodes, the query hangs. 
> Jason debugged this a bit and found:
> {noformat}
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException: 
> org.apache.lucene.queryparser.flexible.messages.MessageImpl
> at 
> org.apache.geode.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1838)
> at 
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:111)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:441)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
> at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: 
> org.apache.lucene.queryparser.flexible.messages.MessageImpl
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at 
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> 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:483)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> {noformat}
> The executing node fails with 
> {noformat}
> [info 2017/05/18 13:50:34.115 PDT server1  
> tid=0x120] Unexpected exception during function execution on local node 
> Partitioned Region
> org.apache.geode.cache.execute.FunctionException: 
> org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
> *asdf*
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:163)
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:332)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution$1.run(AbstractExecution.java:274)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(Distribut

[jira] [Commented] (GEODE-2943) Invalid queryStrings cause lucene searches to hang in in PR with multiple nodes

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2943:


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

GEODE-2943: Wildcard and space queries are now handled correctly


> Invalid queryStrings cause lucene searches to hang in in PR with multiple 
> nodes
> ---
>
> Key: GEODE-2943
> URL: https://issues.apache.org/jira/browse/GEODE-2943
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Affects Versions: 1.2.0
>Reporter: Shelley Lynn Hughes-Godfrey
>
> Some invalid query strings might be "*" or " ".
> When used with a single node dataStore, we see the correct Exception returned:
> {noformat}
> gfsh>search lucene --name=testIndex --region=/testRegion --queryStrings="*" 
> --defaultField=__REGION_VALUE_FIELD
> Could not process command due to GemFire error. An error occurred while 
> searching lucene index across the Geode cluster: Leading wildcard is not 
> allowed: __REGION_VALUE_FIELD:*
> {noformat}
> However, with multiple nodes, the query hangs. 
> Jason debugged this a bit and found:
> {noformat}
> org.apache.geode.InternalGemFireException: java.io.NotSerializableException: 
> org.apache.lucene.queryparser.flexible.messages.MessageImpl
> at 
> org.apache.geode.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1838)
> at 
> org.apache.geode.distributed.internal.ReplyMessage.send(ReplyMessage.java:111)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.sendReply(PartitionMessage.java:441)
> at 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:421)
> at 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:442)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at 
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:625)
> at 
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1071)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.NotSerializableException: 
> org.apache.lucene.queryparser.flexible.messages.MessageImpl
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
> at 
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
> at 
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
> at 
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
> at 
> java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
> at java.lang.Throwable.writeObject(Throwable.java:985)
> 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:483)
> at 
> java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:988)
> at 
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1496)
> {noformat}
> The executing node fails with 
> {noformat}
> [info 2017/05/18 13:50:34.115 PDT server1  
> tid=0x120] Unexpected exception during function execution on local node 
> Partitioned Region
> org.apache.geode.cache.execute.FunctionException: 
> org.apache.geode.cache.lucene.LuceneQueryException: Malformed lucene query: 
> *asdf*
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.getQuery(LuceneQueryFunction.java:163)
> at 
> org.apache.geode.cache.lucene.internal.distributed.LuceneQueryFunction.execute(LuceneQueryFunction.java:87)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:332)
> at 
> org.apache.geode.internal.cache.execute.AbstractExecution$1.run(AbstractExecution.java:274)
> at 
> java.util.concurrent.Thr

Re: Review Request 59404: GEODE-2939: make sure event tracker is initiated from the GII provider

[Darrel Schneider]

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




geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java
Lines 288 (patched)


To avoid a race condition that results in an NPE do this:
rp = this.createRegionReplyProcessor;
if (rp != null) {
  rp.getRemoteEventStates().put(member, eventStates);
}



geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java
Lines 301 (patched)


Instead of exposing the entire private Map by having a getRemoteEventStates 
method, just add a getEventState(InternalDistributedMember) method and use that 
here.



geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
Lines 100 (patched)


instead of casting to LocalRegion it would be better to add 
"registerCreateRegionReplyProcessor" to CacheDistributionAdvisee. Add it as a 
"default" method that does nothing. Then you only need to override it on 
BucketRegion. No need to add a noop to LocalRegion.



geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
Line 202 (original), 204 (patched)


make this final



geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
Line 250 (original), 252 (patched)


I see no need for you to go to "lr" for this. Can't you record it locally 
in your own 'remoteEventStates' map? This allows you to completely get rid of 
the recordPendingEventState.

Also get rid of "lr.hasEventTracker". If you get a non-null eventState back 
just stick it in your local remoteEventStates map.



geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
Lines 542 (patched)


This comment is not needed. You method name makes this clear.



geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
Lines 543 (patched)


Move this call down to line 554 right before the call of endGetInitialImage



geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
Lines 544 (patched)


Since "this.region" is a DistributedRegion it would be best for this method 
to start on it instead of LocalRegion.


- Darrel Schneider


On May 23, 2017, 10:55 a.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59404/
> ---
> 
> (Updated May 23, 2017, 10:55 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2939
> https://issues.apache.org/jira/browse/GEODE-2939
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Event tracker initilization for bucket region is delayed until after GII, and 
> will be initialized from the GII provider.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 886d678 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
>  c1d1e77 
>   geode-core/src/main/java/org/apache/geode/internal/cache/EventTracker.java 
> 2c86aed 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
>  fb5f0cf 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> 8e7ec68 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EventTrackerDUnitTest.java
>  3faf41f 
> 
> 
> Diff: https://reviews.apache.org/r/59404/diff/2/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Commented] (GEODE-231) Remove deprecated AttributesMutator.setCacheListener

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-231:
--

Github user dschneider-pivotal commented on the issue:

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


> Remove deprecated AttributesMutator.setCacheListener
> 
>
> Key: GEODE-231
> URL: https://issues.apache.org/jira/browse/GEODE-231
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> It looks like AttributesMutator.setCacheListener is currently only called 
> from test code. All of these calls can be replaced with 
> AttributesMutator.initCacheListeners with an array of one listener.
> It is probably not safe to use AttributesMutator.addCacheListener since it 
> leaves an original listeners in place.
> The method is called in about 25 different tests.



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

[GitHub] geode issue #507: GEODE-231 : Remove deprecated AttributesMutator.setCacheLi...

[dschneider-pivotal]

Github user dschneider-pivotal commented on the issue:

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


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

Re: Review Request 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Kirk Lund]

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




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


I wonder if it would be better to move these mbean finder methods to their 
own class specific to finding mbeans? These would be useful outside of cli 
commands.



geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/SharedConfiguration.java
Lines 30 (patched)


Maybe name this ClusterConfiguration instead?


- Kirk Lund


On May 23, 2017, 5:01 p.m., Jared Stewart wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59492/
> ---
> 
> (Updated May 23, 2017, 5:01 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> - Extract several commands out of LauncherLifecycleCommands into their 
> distinct own classes.
>  - Extract some utility methods from LauncherLifecycleCommands into more 
> appropriate locations.
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  27bc098d77c05d7385856e6fa4b769a7a2247a0e 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
>  2a1662e318986b1520940403e7c881a2713c8920 
>   geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
> ce660578f4ddef1e733562e94f84a944cf1d3427 
>   geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
> 12c5c2154a2e95fcd45c0414bb7f46add07e5973 
>   geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
> a6d3064404a247f5d669ea7aff0cdd37e11e4583 
>   
> geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
>  18fca984b5792f096cc8b1755b09e65efbdd0d05 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
>  26b903b3895f7f01f01684c44cc320129c80f81e 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
>  b6c11c42731b4158dc16db3586c2a0ba9c5d7b79 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055cbd61ca35ef7409ff3370214a005da3d9b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/HostUtils.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/JdkTool.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/SharedConfiguration.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommandTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/HostUtilsTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/JdkToolTest.java
>  PRE-CREATION 
> 
> 
> Diff: https://reviews.apache.org/r/59492/diff/1/
> 
> 
> Testing
> ---
> 
> Precheckin running
> 
> 
> Thanks,
> 
> Jared Stewart
> 
>

Build failed in Jenkins: Geode-spark-connector #160

[Apache Jenkins Server]

See 

--
Started by upstream project "Geode-nightly" build number 844
originally caused by:
 Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on couchdb-macos1 (couchdb) in workspace 

java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1279)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:405)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1279)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:405)
Retrying after 10 seconds
java.io.IOException: Failed to mkdirs: 

at hudson.FilePath.mkdirs(FilePath.java:1169)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1279)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:604)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:529)
at hudson.model.Run.execute(Run.java:1728)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:405)
Recording test results
ERROR: Build step failed with exception
 does not exist.
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:483)
at 
org.apache.tools.ant.types.AbstractFileSet.getDirectoryScanner(AbstractFileSet.java:460)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:127)
at 
hudson.tasks.junit.JUnitParser$ParseResultCallable.invoke(JUnitParser.java:107)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2731)
at hudson.remoting.UserRequest.perform(UserRequest.java:153)
at hudson.remoting.UserRequest.perform(UserRequest.java:50)
at hudson.remoting.Request$2.run(Request.java:336)
at 
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at hudson.remoting.Engine$1$1.run(Engine.java:94)
at java.lang.Thread.run(Thread.java:745)
at ..remote call to JNLP4-connect connection from 
91.65.50.62/91.65.50.62:51038(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
at hudson.remoting.Channel.call(Channel.java:830)
at hudson.FilePath.act(FilePath.java:985)
at hudson.FilePath.act(FilePath.java:974)
at hudson.tasks.junit.JUnitParser.parseResult(JUnitParser.java:103)
at 
hudson.tasks.junit.JUnitResultArchiver.parse(JUnitResultArchiver.java:128)
at 
hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:149)
at 
hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:78)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:779)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:720)

Jenkins build is back to normal : Geode-nightly #844

[Apache Jenkins Server]

See 

[jira] [Commented] (GEODE-2964) NPE on gfsh put command

[Jinmei Liao (JIRA)]

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

Jinmei Liao commented on GEODE-2964:


this is actually Caused by: java.lang.ClassNotFoundException: 
org.apache.commons.collections.CollectionUtils

It looks like the usage the usage of CollectionUtils is added recently. 
Reverting that fixed this problem.

> NPE on gfsh put command
> ---
>
> Key: GEODE-2964
> URL: https://issues.apache.org/jira/browse/GEODE-2964
> Project: Geode
>  Issue Type: Bug
>  Components: gfsh
>Reporter: Swapnil Bawaskar
>
> After seeing up one locator one server, I created a partitioned region and 
> try to put a value in it from gfsh which resulted in a NPE:
> {noformat}
> gfsh>start locator --name=loc1
> gfsh>start server --name=serv1
> gfsh>create region --name=foo --type=PARTITION
> gfsh>put --key=1 --value=one --region=/foo
> 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 
> com.sun.jmx.mbeanserver.ConvertingMethod.invokeWithOpenReturn(ConvertingMethod.java:175)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:117)
>   at 
> com.sun.jmx.mbeanserver.MXBeanIntrospector.invokeM2(MXBeanIntrospector.java:54)
>   at 
> com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
>   at com.sun.jmx.mbeanserver.PerInterface.invoke(PerInterface.java:138)
>   at com.sun.jmx.mbeanserver.MBeanSupport.invoke(MBeanSupport.java:252)
>   at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
>   at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1401)
>   at 
> javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829)
>   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.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:346)
>   at 

Re: Review Request 59404: GEODE-2939: make sure event tracker is initiated from the GII provider

[Eric Shu]

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

(Updated May 23, 2017, 5:55 p.m.)


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


Changes
---

fix review comments


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


Repository: geode


Description
---

Event tracker initilization for bucket region is delayed until after GII, and 
will be initialized from the GII provider.


Diffs (updated)
-

  geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
886d678 
  
geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
 c1d1e77 
  geode-core/src/main/java/org/apache/geode/internal/cache/EventTracker.java 
2c86aed 
  
geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
 fb5f0cf 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
8e7ec68 
  
geode-core/src/test/java/org/apache/geode/internal/cache/EventTrackerDUnitTest.java
 3faf41f 


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

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


Testing
---

precheckin.


Thanks,

Eric Shu

Re: Review Request 59404: GEODE-2939: make sure event tracker is initiated from the GII provider

[Eric Shu]

> On May 23, 2017, 12:34 a.m., anilkumar gingade wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
> > Line 251 (original), 253 (patched)
> > 
> >
> > Do we need to assert here or do as in following logic (line#263):
> > if (lr.isUsedForPartitionedRegionBucket())
> > 
> > It looks like, this could be called for non-pr bucket region...Where is 
> > the recordEvent set for non bucket region.

Only BucketRegion sends event states back in CreateRegionReplyMessage, this 
assert is to alert future changes if any. But it is no longer needed as it is 
handled in the BucketRegion now.


- Eric


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


On May 19, 2017, 3:38 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59404/
> ---
> 
> (Updated May 19, 2017, 3:38 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, and Lynn 
> Gallinat.
> 
> 
> Bugs: GEODE-2939
> https://issues.apache.org/jira/browse/GEODE-2939
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Event tracker initilization for bucket region is delayed until after GII, and 
> will be initialized from the GII provider.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/cache/BucketRegion.java 
> 886d678 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/CreateRegionProcessor.java
>  c1d1e77 
>   geode-core/src/main/java/org/apache/geode/internal/cache/EventTracker.java 
> 2c86aed 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/InitialImageOperation.java
>  fb5f0cf 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/EventTrackerDUnitTest.java
>  3faf41f 
> 
> 
> Diff: https://reviews.apache.org/r/59404/diff/1/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

[jira] [Commented] (GEODE-231) Remove deprecated AttributesMutator.setCacheListener

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-231:
--

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

https://github.com/apache/geode/pull/507#discussion_r118060767
  
--- Diff: 
geode-junit/src/main/java/org/apache/geode/test/junit/rules/UseJacksonForJsonPathRule.java
 ---
@@ -14,19 +14,18 @@
  */
 package org.apache.geode.test.junit.rules;
 
-import java.util.EnumSet;
-import java.util.Set;
--- End diff --

I see no reason why this import reorg should be part of this pull request.


> Remove deprecated AttributesMutator.setCacheListener
> 
>
> Key: GEODE-231
> URL: https://issues.apache.org/jira/browse/GEODE-231
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> It looks like AttributesMutator.setCacheListener is currently only called 
> from test code. All of these calls can be replaced with 
> AttributesMutator.initCacheListeners with an array of one listener.
> It is probably not safe to use AttributesMutator.addCacheListener since it 
> leaves an original listeners in place.
> The method is called in about 25 different tests.



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

[GitHub] geode pull request #507: GEODE-231 : Remove deprecated AttributesMutator.set...

[dschneider-pivotal]

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

https://github.com/apache/geode/pull/507#discussion_r118060767
  
--- Diff: 
geode-junit/src/main/java/org/apache/geode/test/junit/rules/UseJacksonForJsonPathRule.java
 ---
@@ -14,19 +14,18 @@
  */
 package org.apache.geode.test.junit.rules;
 
-import java.util.EnumSet;
-import java.util.Set;
--- End diff --

I see no reason why this import reorg should be part of this pull request.


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

[jira] [Commented] (GEODE-240) Remove deprecated methods on TransactionEvent

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on GEODE-240:
--

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/515
  
This looks good


> Remove deprecated methods on TransactionEvent
> -
>
> Key: GEODE-240
> URL: https://issues.apache.org/jira/browse/GEODE-240
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Darrel Schneider
>Assignee: Shankar Hundekar
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> The following methods should all be deleted from TransactionEvent and callers 
> should be changed to instead use getEvents. The caller may have to do its own 
> filtering on getEvents to find the event(s) it is interested in.
> - getCreateEvents
> - getDestroyEvents
> - getPutEvents
> - getInvalidateEvents
> Some of the existing unit tests depend on the filtering done by these methods 
> so that filtering will need to move to some test util methods.



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

[GitHub] geode issue #515: GEODE-240: Remove deprecated methods on TransactionEvent

[dschneider-pivotal]

Github user dschneider-pivotal commented on the issue:

https://github.com/apache/geode/pull/515
  
This looks good


---
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-2962) Need more friendly locator's log message when executing "gfsh compact disk-store" command

[ASF GitHub Bot (JIRA)]

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

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

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

https://github.com/apache/geode/pull/525#discussion_r118057642
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -485,9 +485,14 @@ public Result compactDiskStore(
   memberCompactInfo.clear();
 }
 String notExecutedMembers = 
CompactRequest.getNotExecutedMembers();
+if (notExecutedMembers != null && 
!notExecutedMembers.isEmpty()) {
+  notExecutedMembers = "but was not send to " + 
notExecutedMembers;
+} else {
+  notExecutedMembers = "all the members";
--- End diff --

I think this log message only needs to say something if 
"notExecutedMembers" is not null and not empty.
No need for a message in the else. You will notice that immediately after 
this code is a report of what was compacted so it seem to me too verbose to say 
"I sent the request to everyone".

But it could be helpful to log a note of the members that did not receive 
the request.
So I think you should put the log lines 493-496 inside this if and get rid 
of the else.


> Need more friendly locator's log message when executing "gfsh compact 
> disk-store" command
> -
>
> Key: GEODE-2962
> URL: https://issues.apache.org/jira/browse/GEODE-2962
> Project: Geode
>  Issue Type: Wish
>  Components: persistence
>Reporter: Akihiro Kitada
>Priority: Minor
>
> When executing "gfsh compact disk-store" command, then we currently see the 
> following kind of issue if the command is successfully executed for all the 
> target members.
> {noformat}
> compact disk-store "DEFAULT" message was scheduled to be sent to but was not 
> send to null
> {noformat}
> This message is not friendly to know what was going on.
> Need more friendly log message.



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

[GitHub] geode pull request #525: GEODE-2962: Add more messages for compact disk-stor...

[dschneider-pivotal]

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

https://github.com/apache/geode/pull/525#discussion_r118057642
  
--- Diff: 
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/DiskStoreCommands.java
 ---
@@ -485,9 +485,14 @@ public Result compactDiskStore(
   memberCompactInfo.clear();
 }
 String notExecutedMembers = 
CompactRequest.getNotExecutedMembers();
+if (notExecutedMembers != null && 
!notExecutedMembers.isEmpty()) {
+  notExecutedMembers = "but was not send to " + 
notExecutedMembers;
+} else {
+  notExecutedMembers = "all the members";
--- End diff --

I think this log message only needs to say something if 
"notExecutedMembers" is not null and not empty.
No need for a message in the else. You will notice that immediately after 
this code is a report of what was compacted so it seem to me too verbose to say 
"I sent the request to everyone".

But it could be helpful to log a note of the members that did not receive 
the request.
So I think you should put the log lines 493-496 inside this if and get rid 
of the else.


---
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-2918) ConflictingPersistentDataException is not handled properly

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2918:


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

GEODE-2918 Close cache when ConflictingPersistentDataException is thrown.

During disk recovery the ConflictingPersistentDataException is not handled
properly; it should have logged an error and closed the cache.
When it is handled incorrectly, the cache is in inconsistent state; causing
other operations to fail in unexpected ways.


> ConflictingPersistentDataException is not handled properly
> --
>
> Key: GEODE-2918
> URL: https://issues.apache.org/jira/browse/GEODE-2918
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Reporter: Anilkumar Gingade
>  Labels: storage_2
>
> During disk recovery the ConflictingPersistentDataException is not handled 
> properly; it should have logged an error and closed the cache.
> When it is handled incorrectly, the cache is in inconsistent state; causing 
> other operations to fail in unexpected ways.



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

Re: Issues due to Special exceptions in RVV

[Darrel Schneider]

I see that this test directly calls initializeFrom but the product never
does this.
The product always calls it through this method:

org.apache.geode.internal.cache.versions.RegionVersionVector.initializeVersionHolder(T,
RegionVersionHolder)

I can see that initializeVersionHolder checks a memberToVersion map and on
a miss does not call initializeFrom but instead add the new member's RVV to
the memberToVersion map. Have you considered if calling
initializeVersionHolder would fix the issues you are seeing?


On Tue, May 23, 2017 at 10:04 AM, Darrel Schneider 
wrote:

> I made these modifications and the following compiles, runs, and fails on
> geode.
> I added the following to RegionVersionVectorJUnitTest:
>   @Test
>   public void testInitialized() {
>
> RegionVersionHolder vh1 = new RegionVersionHolder<>("vh1");
> vh1.recordVersion(56);
> vh1.recordVersion(57);
> vh1.recordVersion(58);
> vh1.recordVersion(59);
> vh1.recordVersion(60);
> assertTrue(vh1.contains(57));
> vh1 = vh1.clone();
> assertTrue(vh1.contains(57));
> System.out.println("This node init, vh1="+vh1);
>
> RegionVersionHolder vh2 = new RegionVersionHolder<>("vh2");
> for(int i=1;i<57;i++) {
>   vh2.recordVersion(i);
> }
> vh2 = vh2.clone();
> System.out.println("GII node init, vh2="+vh2);
>
> vh1.initializeFrom(vh2);
> // assertTrue(vh1.contains(57)); // fails
> vh1 = vh1.clone();
> System.out.println("After initialize, vh1="+vh1);
>
> vh1.recordVersion(58);
> vh1.recordVersion(59);
> vh1.recordVersion(60);
>
> System.out.println("After initialize and record version, vh1="+vh1);
>
> vh1 = vh1.clone();
> vh1.recordVersion(57);
> System.out.println("After initialize and record version after clone,
> vh1="+vh1);
>
> assertTrue(vh1.contains(57)); //FAILS
>   }
>
>
> On Tue, May 23, 2017 at 9:37 AM, Kirk Lund  wrote:
>
>> Are you sure you're using Geode? The signature of
>> RegionVersionHolder#recordVersion
>> in Geode is:
>>
>> RegionVersionHolder#recordVersion(long)
>>
>> I recommend checking out develop branch of Geode, write a test to confirm
>> your bug and then submit that test with a Jira ticket.
>>
>> On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar > >
>> wrote:
>>
>> > Hi Bruce/Dan,
>> >
>> >  #1. I see some issues due to introduction of special exceptions in the
>> > RegionVersionHolder. In some cases, it is leading to RegionVersionHolder
>> > data structure corruption causing wrong contains(version) results.
>> >
>> >  This happens because we set the version to max of currentVersion or
>> newly
>> > recorded one. But do not try to fix the special exception present if
>> any.
>> >
>> >  It is easily reproducible even in junit tests.
>> > The corruption of holder data stricture causes even future record
>> operation
>> > to fail.
>> > For example the following test fails:
>> >
>> >  public void testInitialized() {
>> >
>> >   RegionVersionHolder vh1 = new RegionVersionHolder(member);
>> >   vh1.recordVersion(56, null);
>> >   vh1.recordVersion(57, null);
>> >   vh1.recordVersion(58, null);
>> >   vh1.recordVersion(59, null);
>> >   vh1.recordVersion(60, null);
>> >   vh1 = vh1.clone();
>> >   System.out.println("This node init, vh1="+vh1);
>> >
>> >   RegionVersionHolder vh2 = new RegionVersionHolder(member);
>> >   for(int i=1;i<57;i++) {
>> > vh2.recordVersion(i,null);
>> >   }
>> >   vh2 = vh2.clone();
>> >   System.out.println("GII node init, vh2="+vh2);
>> >
>> >   vh1.initializeFrom(vh2);
>> >   vh1 = vh1.clone();
>> >   System.out.println("After initialize, vh1="+vh1);
>> >
>> >
>> >   vh1.recordVersion(58,null);
>> >   vh1.recordVersion(59,null);
>> >   vh1.recordVersion(60,null);
>> >
>> >   System.out.println("After initialize and record version, vh1="+vh1);
>> >
>> >   vh1 = vh1.clone();
>> >   vh1.recordVersion(57,null);
>> >   System.out.println("After initialize and record version after clone,
>> > vh1="+vh1);
>> >
>> >   assertTrue(vh1.contains(57)); //FAILS
>> > }
>> >
>> >
>> >  #2. I have observed that
>> > RegionVersionHolder#initializeFrom(RegionVersionHolder source)
>> > doesn't not record already recorded version in itself contrary to what
>> > the comment above the method claims. In fact the junit tests also
>> > verifies the same so I couldn't understand the rationale behind it. It
>> > just adds an special exception if any higher version was already
>> > recorded by self.
>> >  Shouldn't the resulting holder after initializing from a source
>> > contain records for both the holders? If not then why do we even need
>> > special exception.
>> >
>> > If possible could you please let me know your thoughts on this.
>> >
>> > Regards,
>> > Suranjan Kumar
>> >
>>
>
>

[jira] [Resolved] (GEODE-2956) gfsh lucene create index should trim from analyzer names

[David Anuta (JIRA)]

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

David Anuta resolved GEODE-2956.

   Resolution: Fixed
Fix Version/s: 1.2.0

> gfsh lucene create index should trim from analyzer names
> 
>
> Key: GEODE-2956
> URL: https://issues.apache.org/jira/browse/GEODE-2956
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
> Fix For: 1.2.0
>
>
> When creating an index with specific analyzers, the parameter expects a comma 
> separated string.  However this comma separated string must have no spaces 
> before or after the comma.  If one exists, it attempts to find an analyzer 
> class with the starting or trailing whitespace. This leads to an even more 
> hard to read command.  
> The command should properly trim spaces before doing the class lookup.



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

[jira] [Assigned] (GEODE-2956) gfsh lucene create index should trim from analyzer names

[David Anuta (JIRA)]

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

David Anuta reassigned GEODE-2956:
--

Assignee: David Anuta  (was: Jason Huynh)

> gfsh lucene create index should trim from analyzer names
> 
>
> Key: GEODE-2956
> URL: https://issues.apache.org/jira/browse/GEODE-2956
> Project: Geode
>  Issue Type: Bug
>  Components: lucene
>Reporter: Jason Huynh
>Assignee: David Anuta
>
> When creating an index with specific analyzers, the parameter expects a comma 
> separated string.  However this comma separated string must have no spaces 
> before or after the comma.  If one exists, it attempts to find an analyzer 
> class with the starting or trailing whitespace. This leads to an even more 
> hard to read command.  
> The command should properly trim spaces before doing the class lookup.



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

Re: Requesting Permisions

[Dan Smith]

Hi David,

I added you; you should have permission now.

Thanks!
-Dan

On Tue, May 23, 2017 at 10:10 AM, David Anuta 
wrote:

> Hi my name is David Anuta. My Geode username is DivineEnder. I would like
> permission to contribute to the Geode project by assigning myself to an
> issue.
>
> --
> David Anuta
>
> Sophomore
> University of Rochester
> Working towards dual degree:
>
> B.S. in Computer Science
>
> B.S. in Physics
>
> Graduation expected May 2019
>
> Contact:
> Phone -- 503-707-6814
> Alt Email -- dan...@u.rochester.edu
> Mailing Address:
> CMC Box 273213
> 500 Joseph C. Wilson Blvd.
> Rochester, NY 14627
>

Requesting Permisions

[David Anuta]

Hi my name is David Anuta. My Geode username is DivineEnder. I would like
permission to contribute to the Geode project by assigning myself to an
issue.

-- 
David Anuta

Sophomore
University of Rochester
Working towards dual degree:

B.S. in Computer Science

B.S. in Physics

Graduation expected May 2019

Contact:
Phone -- 503-707-6814
Alt Email -- dan...@u.rochester.edu
Mailing Address:
CMC Box 273213
500 Joseph C. Wilson Blvd.
Rochester, NY 14627

Re: Issues due to Special exceptions in RVV

[Darrel Schneider]

I made these modifications and the following compiles, runs, and fails on
geode.
I added the following to RegionVersionVectorJUnitTest:
  @Test
  public void testInitialized() {

RegionVersionHolder vh1 = new RegionVersionHolder<>("vh1");
vh1.recordVersion(56);
vh1.recordVersion(57);
vh1.recordVersion(58);
vh1.recordVersion(59);
vh1.recordVersion(60);
assertTrue(vh1.contains(57));
vh1 = vh1.clone();
assertTrue(vh1.contains(57));
System.out.println("This node init, vh1="+vh1);

RegionVersionHolder vh2 = new RegionVersionHolder<>("vh2");
for(int i=1;i<57;i++) {
  vh2.recordVersion(i);
}
vh2 = vh2.clone();
System.out.println("GII node init, vh2="+vh2);

vh1.initializeFrom(vh2);
// assertTrue(vh1.contains(57)); // fails
vh1 = vh1.clone();
System.out.println("After initialize, vh1="+vh1);

vh1.recordVersion(58);
vh1.recordVersion(59);
vh1.recordVersion(60);

System.out.println("After initialize and record version, vh1="+vh1);

vh1 = vh1.clone();
vh1.recordVersion(57);
System.out.println("After initialize and record version after clone,
vh1="+vh1);

assertTrue(vh1.contains(57)); //FAILS
  }


On Tue, May 23, 2017 at 9:37 AM, Kirk Lund  wrote:

> Are you sure you're using Geode? The signature of
> RegionVersionHolder#recordVersion
> in Geode is:
>
> RegionVersionHolder#recordVersion(long)
>
> I recommend checking out develop branch of Geode, write a test to confirm
> your bug and then submit that test with a Jira ticket.
>
> On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar 
> wrote:
>
> > Hi Bruce/Dan,
> >
> >  #1. I see some issues due to introduction of special exceptions in the
> > RegionVersionHolder. In some cases, it is leading to RegionVersionHolder
> > data structure corruption causing wrong contains(version) results.
> >
> >  This happens because we set the version to max of currentVersion or
> newly
> > recorded one. But do not try to fix the special exception present if any.
> >
> >  It is easily reproducible even in junit tests.
> > The corruption of holder data stricture causes even future record
> operation
> > to fail.
> > For example the following test fails:
> >
> >  public void testInitialized() {
> >
> >   RegionVersionHolder vh1 = new RegionVersionHolder(member);
> >   vh1.recordVersion(56, null);
> >   vh1.recordVersion(57, null);
> >   vh1.recordVersion(58, null);
> >   vh1.recordVersion(59, null);
> >   vh1.recordVersion(60, null);
> >   vh1 = vh1.clone();
> >   System.out.println("This node init, vh1="+vh1);
> >
> >   RegionVersionHolder vh2 = new RegionVersionHolder(member);
> >   for(int i=1;i<57;i++) {
> > vh2.recordVersion(i,null);
> >   }
> >   vh2 = vh2.clone();
> >   System.out.println("GII node init, vh2="+vh2);
> >
> >   vh1.initializeFrom(vh2);
> >   vh1 = vh1.clone();
> >   System.out.println("After initialize, vh1="+vh1);
> >
> >
> >   vh1.recordVersion(58,null);
> >   vh1.recordVersion(59,null);
> >   vh1.recordVersion(60,null);
> >
> >   System.out.println("After initialize and record version, vh1="+vh1);
> >
> >   vh1 = vh1.clone();
> >   vh1.recordVersion(57,null);
> >   System.out.println("After initialize and record version after clone,
> > vh1="+vh1);
> >
> >   assertTrue(vh1.contains(57)); //FAILS
> > }
> >
> >
> >  #2. I have observed that
> > RegionVersionHolder#initializeFrom(RegionVersionHolder source)
> > doesn't not record already recorded version in itself contrary to what
> > the comment above the method claims. In fact the junit tests also
> > verifies the same so I couldn't understand the rationale behind it. It
> > just adds an special exception if any higher version was already
> > recorded by self.
> >  Shouldn't the resulting holder after initializing from a source
> > contain records for both the holders? If not then why do we even need
> > special exception.
> >
> > If possible could you please let me know your thoughts on this.
> >
> > Regards,
> > Suranjan Kumar
> >
>

Review Request 59492: GEODE-2966: Refactor LauncherLifecycleCommands (Part 1)

[Jared Stewart]

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

Review request for geode, Jinmei Liao, Ken Howe, Kirk Lund, and Patrick 
Rhomberg.


Repository: geode


Description
---

- Extract several commands out of LauncherLifecycleCommands into their distinct 
own classes.
 - Extract some utility methods from LauncherLifecycleCommands into more 
appropriate locations.


Diffs
-

  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
 27bc098d77c05d7385856e6fa4b769a7a2247a0e 
  
geode-assembly/src/test/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommandsTest.java
 2a1662e318986b1520940403e7c881a2713c8920 
  geode-core/src/main/java/org/apache/geode/distributed/AbstractLauncher.java 
ce660578f4ddef1e733562e94f84a944cf1d3427 
  geode-core/src/main/java/org/apache/geode/distributed/LocatorLauncher.java 
12c5c2154a2e95fcd45c0414bb7f46add07e5973 
  geode-core/src/main/java/org/apache/geode/distributed/ServerLauncher.java 
a6d3064404a247f5d669ea7aff0cdd37e11e4583 
  
geode-core/src/main/java/org/apache/geode/internal/process/ProcessStreamReader.java
 18fca984b5792f096cc8b1755b09e65efbdd0d05 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/AbstractCommandsSupport.java
 26b903b3895f7f01f01684c44cc320129c80f81e 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/LauncherLifecycleCommands.java
 b6c11c42731b4158dc16db3586c2a0ba9c5d7b79 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJVisualVMCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartPulseCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartVsdCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusLocatorCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StatusServerCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopLocatorCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/lifecycle/StopServerCommand.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 68d055cbd61ca35ef7409ff3370214a005da3d9b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/HostUtils.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/JdkTool.java
 PRE-CREATION 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/utils/SharedConfiguration.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/lifecycle/StartJConsoleCommandTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/HostUtilsTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/JdkToolTest.java
 PRE-CREATION 


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


Testing
---

Precheckin running


Thanks,

Jared Stewart

[jira] [Commented] (GEODE-2741) Use C++11 shared pointer over custom shared pointer

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2741:


Commit 2796a8955e2f23a908f696a083784ebf72fe7520 in geode-native's branch 
refs/heads/develop from Jacob Barrett
[ https://git-wip-us.apache.org/repos/asf?p=geode-native.git;h=2796a89 ]

GEODE-2741: Update Linux build to JDK 8 update 131.

> Use C++11 shared pointer over custom shared pointer
> ---
>
> Key: GEODE-2741
> URL: https://issues.apache.org/jira/browse/GEODE-2741
> Project: Geode
>  Issue Type: Improvement
>  Components: native client
>Reporter: Addison
>Assignee: Jacob S. Barrett
>
> *Context*
> Now that the Native Client is compatible with C++11, we can use its shared 
> pointer over the custom shared pointer we use today.
> *Definition of Done*
> The custom shared pointer is nowhere to be found in the codebase



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

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

[Jinmei Liao (JIRA)]

Jinmei Liao created GEODE-2977:
--

 Summary: commands should take string[] as the value for --group 
and --memberId(--name) whenever possible
 Key: GEODE-2977
 URL: https://issues.apache.org/jira/browse/GEODE-2977
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Reporter: Jinmei Liao


some commands takes string[], and some takes only String and split them 
manually. We should make this consistent and the help message would be a lot 
clearer if taking string[].



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

[jira] [Commented] (GEODE-2420) Warn a user if they try to export too much data

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2420:


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

GEODE-2420: Renamed methods that had signatures changed

Updated javadocs for the renamed methods to explicitly call out the
exceptions thrown


> Warn a user if they try to export too much data
> ---
>
> Key: GEODE-2420
> URL: https://issues.apache.org/jira/browse/GEODE-2420
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, docs, gfsh
>Reporter: Jared Stewart
>Assignee: Kenneth Howe
>
> We should warn a user and prompt for confirmation before trying to perform an 
> `export logs` operation that would result in a file over some threshold.  
> (Logs and stats have the potential to be very large.)



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

[jira] [Commented] (GEODE-2420) Warn a user if they try to export too much data

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2420:


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

GEODE-2420: Resolve conflicts with recent checkin

Use InternalCache instead of GemnFireCachImpl.

Refactored product and tests
- Combined LogExporter and LogSizer.
- Remove classes no longer needed


> Warn a user if they try to export too much data
> ---
>
> Key: GEODE-2420
> URL: https://issues.apache.org/jira/browse/GEODE-2420
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, docs, gfsh
>Reporter: Jared Stewart
>Assignee: Kenneth Howe
>
> We should warn a user and prompt for confirmation before trying to perform an 
> `export logs` operation that would result in a file over some threshold.  
> (Logs and stats have the potential to be very large.)



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

[jira] [Commented] (GEODE-2420) Warn a user if they try to export too much data

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on GEODE-2420:


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

GEODE-2420: Enable export logs size estimation and user warning

Adds 'export logs' option, --file-limit-size, to allow user to set
maximun size of the epxorted logs zip file.

When size checking is enabled (file-limit-size > 0) then the check
will also prevent filling up the disk on each member while consolidating
and filtering the logs.


> Warn a user if they try to export too much data
> ---
>
> Key: GEODE-2420
> URL: https://issues.apache.org/jira/browse/GEODE-2420
> Project: Geode
>  Issue Type: Sub-task
>  Components: configuration, docs, gfsh
>Reporter: Jared Stewart
>Assignee: Kenneth Howe
>
> We should warn a user and prompt for confirmation before trying to perform an 
> `export logs` operation that would result in a file over some threshold.  
> (Logs and stats have the potential to be very large.)



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

[jira] [Commented] (GEODE-2913) Update Lucene documentation

[Karen Smoler Miller (JIRA)]

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

Karen Smoler Miller commented on GEODE-2913:


Work that also must be completed with this ticket:  add Lucene XSD/XML 
definitions to the Reference section of the docs.

> Update Lucene documentation
> ---
>
> Key: GEODE-2913
> URL: https://issues.apache.org/jira/browse/GEODE-2913
> Project: Geode
>  Issue Type: Bug
>  Components: docs
>Reporter: Karen Smoler Miller
>Assignee: Karen Smoler Miller
>
> Improvements to the code base that need to be reflected in the docs:
> * Change LuceneService.createIndex to use a factory pattern
> {code:java}
> luceneService.createIndex(region, index, ...)
> {code}
> changes to
> {code:java}
> luceneService.createIndexFactory()
> .addField("field1name")
> .addField("field2name")
> .create()
> {code}
> *  Lucene indexes will *NOT* be stored in off-heap memory.
> * Document how to configure an index on accessors - you still need to create 
> the Lucene index before creating the region, even though this member does not 
> hold any region data.
> If the index is not defined on the accessor, an exception like this will be 
> thrown while attempting to create the region:
> {quote}
> [error 2017/05/02 15:19:26.018 PDT  tid=0x1] 
> java.lang.IllegalStateException: Must create Lucene index full_index on 
> region /data because it is defined in another member.
> Exception in thread "main" java.lang.IllegalStateException: Must create 
> Lucene index full_index on region /data because it is defined in another 
> member.
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.handleCacheDistributionAdvisee(CreateRegionProcessor.java:478)
> at 
> org.apache.geode.internal.cache.CreateRegionProcessor$CreateRegionMessage.process(CreateRegionProcessor.java:379)
> {quote}
> * Do not need to create a Lucene index on a client with a Proxy cache. The 
> Lucene search will always be done on the server.  Besides, _you can't create 
> an index on a client._
> * If you configure Invalidates for region entries (alone or as part of 
> expiration), these will *NOT* invalidate the Lucene indexes.
> The problem with this is the index contains the keys, but the region doesn't, 
> so the query produces results that don't exist.
> In this test, the first time the query is run, it produces N valid results. 
> The second time it is run it produces N empty results:
> ** load entries
> ** run query
> ** invalidate entries
> ** run query again
> *  Destroying a region will *NOT* automatically destroy any Lucene index 
> associated with that region. Instead, attempting to destroy a region with a 
> Lucene index will throw a colocated region exception. 
> An IllegalStateException is thrown:
> {quote}
> java.lang.IllegalStateException: The parent region [/data] in colocation 
> chain cannot be destroyed, unless all its children 
> [[/cusip_index#_data.files]] are destroyed
> at 
> org.apache.geode.internal.cache.PartitionedRegion.checkForColocatedChildren(PartitionedRegion.java:7231)
> at 
> org.apache.geode.internal.cache.PartitionedRegion.destroyRegion(PartitionedRegion.java:7243)
> at 
> org.apache.geode.internal.cache.AbstractRegion.destroyRegion(AbstractRegion.java:308)
> at 
> DestroyLuceneIndexesAndRegionFunction.destroyRegion(DestroyLuceneIndexesAndRegionFunction.java:46)
> {quote}
> * The process to change a Lucene index using gfsh: 
>   1. export region data
>   2. destroy Lucene index, destroy region 
>   3. create new index, create new region without user-defined business 
> logic callbacks
>   4. import data with option to turn on callbacks (to invoke Lucene Async 
> Event Listener to index the data)
>   5. alter region to add user-defined business logic callbacks
> * Make sure there are no references to replicated regions as they are not 
> supported.
> * Document security implementation and defaults.  If a user has security 
> configured for their cluster, creating a Lucene index requires DATA:MANAGE 
> privilege (similar to OQL), but doing Lucene queries requires DATA:WRITE 
> privilege because a function is called (different from OQL which requires 
> only DATA:READ privilege). Here are all the required privileges for the gfsh 
> commands:
> ** create index requires DATA:MANAGE:region
> ** describe index requires CLUSTER:READ
> ** list indexes requires CLUSTER:READ
> ** search index requires DATA:WRITE
> ** destroy index requires DATA:MANAGE:region
> * A user cannot create a Lucene index on a region that has eviction 
> configured with local destroy. If using Lucene indexing, eviction can only be 
> configured with overflow to disk. In this case, only the region data is 
> overflowed to disk, *NOT* the Lucene index. An Unsupported

Re: Issues due to Special exceptions in RVV

[Kirk Lund]

Are you sure you're using Geode? The signature of
RegionVersionHolder#recordVersion
in Geode is:

RegionVersionHolder#recordVersion(long)

I recommend checking out develop branch of Geode, write a test to confirm
your bug and then submit that test with a Jira ticket.

On Tue, May 23, 2017 at 7:10 AM, Suranjan Kumar 
wrote:

> Hi Bruce/Dan,
>
>  #1. I see some issues due to introduction of special exceptions in the
> RegionVersionHolder. In some cases, it is leading to RegionVersionHolder
> data structure corruption causing wrong contains(version) results.
>
>  This happens because we set the version to max of currentVersion or newly
> recorded one. But do not try to fix the special exception present if any.
>
>  It is easily reproducible even in junit tests.
> The corruption of holder data stricture causes even future record operation
> to fail.
> For example the following test fails:
>
>  public void testInitialized() {
>
>   RegionVersionHolder vh1 = new RegionVersionHolder(member);
>   vh1.recordVersion(56, null);
>   vh1.recordVersion(57, null);
>   vh1.recordVersion(58, null);
>   vh1.recordVersion(59, null);
>   vh1.recordVersion(60, null);
>   vh1 = vh1.clone();
>   System.out.println("This node init, vh1="+vh1);
>
>   RegionVersionHolder vh2 = new RegionVersionHolder(member);
>   for(int i=1;i<57;i++) {
> vh2.recordVersion(i,null);
>   }
>   vh2 = vh2.clone();
>   System.out.println("GII node init, vh2="+vh2);
>
>   vh1.initializeFrom(vh2);
>   vh1 = vh1.clone();
>   System.out.println("After initialize, vh1="+vh1);
>
>
>   vh1.recordVersion(58,null);
>   vh1.recordVersion(59,null);
>   vh1.recordVersion(60,null);
>
>   System.out.println("After initialize and record version, vh1="+vh1);
>
>   vh1 = vh1.clone();
>   vh1.recordVersion(57,null);
>   System.out.println("After initialize and record version after clone,
> vh1="+vh1);
>
>   assertTrue(vh1.contains(57)); //FAILS
> }
>
>
>  #2. I have observed that
> RegionVersionHolder#initializeFrom(RegionVersionHolder source)
> doesn't not record already recorded version in itself contrary to what
> the comment above the method claims. In fact the junit tests also
> verifies the same so I couldn't understand the rationale behind it. It
> just adds an special exception if any higher version was already
> recorded by self.
>  Shouldn't the resulting holder after initializing from a source
> contain records for both the holders? If not then why do we even need
> special exception.
>
> If possible could you please let me know your thoughts on this.
>
> Regards,
> Suranjan Kumar
>

[jira] [Commented] (GEODE-2953) Code Cleanup: Replace wildcard imports with explicit imports

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/522
  
Yeah, while I do firmly believe that there is value in good form and 
adherence to best practices, this PR ended up a lot bigger than I had initially 
expected.


> Code Cleanup: Replace wildcard imports with explicit imports
> 
>
> Key: GEODE-2953
> URL: https://issues.apache.org/jira/browse/GEODE-2953
> Project: Geode
>  Issue Type: Improvement
>  Components: general
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Minor
>
> While optimal import order may be a matter of debate, all style guides seem 
> to agree that wildcard imports should be avoided for improved readability and 
> namespace cleanliness.



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

[jira] [Commented] (GEODE-2953) Code Cleanup: Replace wildcard imports with explicit imports

[ASF GitHub Bot (JIRA)]

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

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

Github user PurelyApplied closed the pull request at:

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


> Code Cleanup: Replace wildcard imports with explicit imports
> 
>
> Key: GEODE-2953
> URL: https://issues.apache.org/jira/browse/GEODE-2953
> Project: Geode
>  Issue Type: Improvement
>  Components: general
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Minor
>
> While optimal import order may be a matter of debate, all style guides seem 
> to agree that wildcard imports should be avoided for improved readability and 
> namespace cleanliness.



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

[GitHub] geode pull request #522: GEODE-2953: Imports optimized in every file with a ...

[PurelyApplied]

Github user PurelyApplied closed the pull request at:

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


---
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 #522: GEODE-2953: Imports optimized in every file with a wildcar...

[PurelyApplied]

Github user PurelyApplied commented on the issue:

https://github.com/apache/geode/pull/522
  
Yeah, while I do firmly believe that there is value in good form and 
adherence to best practices, this PR ended up a lot bigger than I had initially 
expected.


---
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 59287: GEODE-2420: Enable export logs size estimation and user warning

[Kirk Lund]

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


Ship it!




Ship It!

- Kirk Lund


On May 23, 2017, 3:45 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59287/
> ---
> 
> (Updated May 23, 2017, 3:45 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adds 'export logs' option, --file-limit-size, to allow user to set
> maximun size of the epxorted logs zip file.
> 
> When size checking is enabled (file-limit-size > 0) then the check
> will also prevent filling up the disk on each member while consolidating
> and filtering the logs.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  7170f209ffa169fb6efdc851d35b61a2031888b7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  20ec1f5702aea341ace5aa3b103c34cbdce1ae87 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
>  663a08e15624ed3dbc032460133fe3c62fc5ac26 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
>  c175e1ae3def869890692461bd129891350b383c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  8d20dc05c14bf558462893c4dd4cbbc474df4077 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055cbd61ca35ef7409ff3370214a005da3d9b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
>  a0be7fbd83918fccb5254b4a48ba7bf14a0fb344 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
>  0a799f6c85dada2791da57585234fa2e47ef0b3d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  a02c07f2c28156e097306f4b57174cddeda78845 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  96ac76588662b1de5d5bf41c24ab115d90fc0a85 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  ec2bcfe8ea876172c6946c43c005659d23d055e0 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  90a92f33247ecec8ee300ecb80a5d8ab27193c94 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
>  0bfbefa90af7813a8cf20529d36c9cbe5111f9d9 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
>  d8f2f2db937fc51ab5f917659e766f338b9ae847 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
>  e70a750f48a8f7cc3b10b89be9b5934944addb0d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterTest.java
>  a387af3b70f61256b5d9303de29e9402bbdd71e6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
>  c7b3ab934ce1cf97c0a70bc23b50f0f5ca08bb40 
> 
> 
> Diff: https://reviews.apache.org/r/59287/diff/5/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress - all green so far with only DistributedTest still 
> running
> 
> 5/22 - Precheckin being re-run. Currently Green expcet for the known 
> LocatorLauncher test failures. DistributedTests still running
> 
> 5/23 - Re-running precheckin after syncing with current state of develop
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 59287: GEODE-2420: Enable export logs size estimation and user warning

[Jared Stewart]

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


Ship it!




Ship It!

- Jared Stewart


On May 23, 2017, 3:45 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59287/
> ---
> 
> (Updated May 23, 2017, 3:45 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adds 'export logs' option, --file-limit-size, to allow user to set
> maximun size of the epxorted logs zip file.
> 
> When size checking is enabled (file-limit-size > 0) then the check
> will also prevent filling up the disk on each member while consolidating
> and filtering the logs.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  7170f209ffa169fb6efdc851d35b61a2031888b7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  20ec1f5702aea341ace5aa3b103c34cbdce1ae87 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
>  663a08e15624ed3dbc032460133fe3c62fc5ac26 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
>  c175e1ae3def869890692461bd129891350b383c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  8d20dc05c14bf558462893c4dd4cbbc474df4077 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055cbd61ca35ef7409ff3370214a005da3d9b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
>  a0be7fbd83918fccb5254b4a48ba7bf14a0fb344 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
>  0a799f6c85dada2791da57585234fa2e47ef0b3d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  a02c07f2c28156e097306f4b57174cddeda78845 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  96ac76588662b1de5d5bf41c24ab115d90fc0a85 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  ec2bcfe8ea876172c6946c43c005659d23d055e0 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  90a92f33247ecec8ee300ecb80a5d8ab27193c94 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
>  0bfbefa90af7813a8cf20529d36c9cbe5111f9d9 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
>  d8f2f2db937fc51ab5f917659e766f338b9ae847 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
>  e70a750f48a8f7cc3b10b89be9b5934944addb0d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterTest.java
>  a387af3b70f61256b5d9303de29e9402bbdd71e6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
>  c7b3ab934ce1cf97c0a70bc23b50f0f5ca08bb40 
> 
> 
> Diff: https://reviews.apache.org/r/59287/diff/5/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress - all green so far with only DistributedTest still 
> running
> 
> 5/22 - Precheckin being re-run. Currently Green expcet for the known 
> LocatorLauncher test failures. DistributedTests still running
> 
> 5/23 - Re-running precheckin after syncing with current state of develop
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 59287: GEODE-2420: Enable export logs size estimation and user warning

[Ken Howe]

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

(Updated May 23, 2017, 3:45 p.m.)


Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
Rhomberg.


Changes
---

OK, ready to review now. Sorted out the repo sync and manually fixed the 
renames in the tests. The correct changes to review are between revisions 3 & 
5. Ignore revision 4.


Repository: geode


Description
---

Adds 'export logs' option, --file-limit-size, to allow user to set
maximun size of the epxorted logs zip file.

When size checking is enabled (file-limit-size > 0) then the check
will also prevent filling up the disk on each member while consolidating
and filtering the logs.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
 7170f209ffa169fb6efdc851d35b61a2031888b7 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
 20ec1f5702aea341ace5aa3b103c34cbdce1ae87 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
 663a08e15624ed3dbc032460133fe3c62fc5ac26 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
 c175e1ae3def869890692461bd129891350b383c 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
 8d20dc05c14bf558462893c4dd4cbbc474df4077 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
 68d055cbd61ca35ef7409ff3370214a005da3d9b 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
 a0be7fbd83918fccb5254b4a48ba7bf14a0fb344 
  
geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
 0a799f6c85dada2791da57585234fa2e47ef0b3d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
 a02c07f2c28156e097306f4b57174cddeda78845 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
 96ac76588662b1de5d5bf41c24ab115d90fc0a85 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
 ec2bcfe8ea876172c6946c43c005659d23d055e0 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
 90a92f33247ecec8ee300ecb80a5d8ab27193c94 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
 0bfbefa90af7813a8cf20529d36c9cbe5111f9d9 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
 d8f2f2db937fc51ab5f917659e766f338b9ae847 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
 e70a750f48a8f7cc3b10b89be9b5934944addb0d 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterTest.java
 a387af3b70f61256b5d9303de29e9402bbdd71e6 
  
geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
 c7b3ab934ce1cf97c0a70bc23b50f0f5ca08bb40 


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

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


Testing
---

Precheckin is in progress - all green so far with only DistributedTest still 
running

5/22 - Precheckin being re-run. Currently Green expcet for the known 
LocatorLauncher test failures. DistributedTests still running

5/23 - Re-running precheckin after syncing with current state of develop


Thanks,

Ken Howe

Re: Review Request 59287: GEODE-2420: Enable export logs size estimation and user warning

[Ken Howe]

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



Hold off on reviewing this update! The IDE didn't handle the renames correctly, 
and the diff from my repo ended up with some extra changes.

- Ken Howe


On May 23, 2017, 2:52 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/59287/
> ---
> 
> (Updated May 23, 2017, 2:52 p.m.)
> 
> 
> Review request for geode, Jinmei Liao, Jared Stewart, Kirk Lund, and Patrick 
> Rhomberg.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adds 'export logs' option, --file-limit-size, to allow user to set
> maximun size of the epxorted logs zip file.
> 
> When size checking is enabled (file-limit-size > 0) then the check
> will also prevent filling up the disk on each member while consolidating
> and filtering the logs.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/DistributedSystem.java 
> 13a1721ae3967f6503f7a1042b4dddf246b83645 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java
>  7caad3f33ee55f72dc61c4adc2ab3de5429a1607 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/membership/InternalDistributedMember.java
>  7170f209ffa169fb6efdc851d35b61a2031888b7 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommand.java
>  20ec1f5702aea341ace5aa3b103c34cbdce1ae87 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportLogsFunction.java
>  663a08e15624ed3dbc032460133fe3c62fc5ac26 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfo.java
>  c175e1ae3def869890692461bd129891350b383c 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunction.java
>  8d20dc05c14bf558462893c4dd4cbbc474df4077 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/i18n/CliStrings.java
>  68d055cbd61ca35ef7409ff3370214a005da3d9b 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogExporter.java
>  a0be7fbd83918fccb5254b4a48ba7bf14a0fb344 
>   
> geode-core/src/main/java/org/apache/geode/management/internal/cli/util/LogSizer.java
>  0a799f6c85dada2791da57585234fa2e47ef0b3d 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherTest.java
>  d63da8755bed1041296d40ea9821251f01c4c59f 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/xmlcache/CacheXmlParserJUnitTest.java
>  4043888561d4206b1c0b405b3b77d5c9876ad99a 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsCommandTest.java
>  a02c07f2c28156e097306f4b57174cddeda78845 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsDUnitTest.java
>  96ac76588662b1de5d5bf41c24ab115d90fc0a85 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsFileSizeLimitTest.java
>  ec2bcfe8ea876172c6946c43c005659d23d055e0 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/ExportLogsTestSuite.java
>  90a92f33247ecec8ee300ecb80a5d8ab27193c94 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/ExportedLogsSizeInfoTest.java
>  0bfbefa90af7813a8cf20529d36c9cbe5111f9d9 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsFunctionCacheTest.java
>  d8f2f2db937fc51ab5f917659e766f338b9ae847 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/functions/SizeExportLogsTestSuite.java
>  e70a750f48a8f7cc3b10b89be9b5934944addb0d 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogExporterTest.java
>  a387af3b70f61256b5d9303de29e9402bbdd71e6 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/util/LogSizerTest.java
>  c7b3ab934ce1cf97c0a70bc23b50f0f5ca08bb40 
> 
> 
> Diff: https://reviews.apache.org/r/59287/diff/4/
> 
> 
> Testing
> ---
> 
> Precheckin is in progress - all green so far with only DistributedTest still 
> running
> 
> 5/22 - Precheckin being re-run. Currently Green expcet for the known 
> LocatorLauncher test failures. DistributedTests still running
> 
> 5/23 - Re-running precheckin after syncing with current state of develop
> 
> 
> Thanks,
> 
> Ken Howe
> 
>