Re: Review Request 53596: GEODE-1808 Remove broken check for jdk1.7.0_72

[anilkumar gingade]

> On Nov. 9, 2016, 5:36 p.m., anilkumar gingade wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java,
> >  line 1189
> > <https://reviews.apache.org/r/53596/diff/1/?file=1558982#file1558982line1189>
> >
> > This is verifying java version when cache is getting created and warns 
> > the user if its not compatible version...I think we should keep this 
> > instead of removing it...
> 
> Anthony Baker wrote:
> Anil, this is verifying that the java version is at least 1.7.0_72.  It 
> was originally added due to an xml parsing bug in certain jdk versions.  We 
> now require jdk1.8 as a minimum where this is not an issue.  In fact, if you 
> try to run geode with a 1.7 jdk you get a class version exception.
> 
> If you look at the version parsing logic, it's broken anyway when trying 
> to compare {version}_NN with {version}_NNN.  This shows up when trying to run 
> with a jdk9 jvm.

Got it, thanks...


- anilkumar


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


On Nov. 9, 2016, 5:08 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53596/
> ---
> 
> (Updated Nov. 9, 2016, 5:08 a.m.)
> 
> 
> Review request for geode, Jacob Barrett and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The logic for evaluating jdk versions is incorrect for 3-digit builds.
> Since we require a jdk1.8 version anyway, remove the check.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  e1b2007c12804d3fb668ef42e976b8f5a1bcb3d5 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/MinimumSystemRequirements.java
>  a2c1874d9b37ee0268a6848a4c4ca98dc92cc16f 
>   
> geode-core/src/test/java/org/apache/geode/internal/lang/SystemUtilsJUnitTest.java
>  fbe18d048bfce2bb1ce7fb30962f97bec52b5091 
> 
> Diff: https://reviews.apache.org/r/53596/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 53596: GEODE-1808 Remove broken check for jdk1.7.0_72

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
<https://reviews.apache.org/r/53596/#comment225432>

This is verifying java version when cache is getting created and warns the 
user if its not compatible version...I think we should keep this instead of 
removing it...


- anilkumar gingade


On Nov. 9, 2016, 5:08 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53596/
> ---
> 
> (Updated Nov. 9, 2016, 5:08 a.m.)
> 
> 
> Review request for geode, Jacob Barrett and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The logic for evaluating jdk versions is incorrect for 3-digit builds.
> Since we require a jdk1.8 version anyway, remove the check.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  e1b2007c12804d3fb668ef42e976b8f5a1bcb3d5 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/MinimumSystemRequirements.java
>  a2c1874d9b37ee0268a6848a4c4ca98dc92cc16f 
>   
> geode-core/src/test/java/org/apache/geode/internal/lang/SystemUtilsJUnitTest.java
>  fbe18d048bfce2bb1ce7fb30962f97bec52b5091 
> 
> Diff: https://reviews.apache.org/r/53596/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 53442: GEODE-1740: Correct potential region inconsistencies with concurrent clear and transaction commit

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java (line 514)
<https://reviews.apache.org/r/53442/#comment225040>

What if one of the region is destroyed while iterating over the regions? 
Can we still operate on version vector (in lockRegionForAtomicTX())...Do we 
need to have some error handlling code?


- anilkumar gingade


On Nov. 3, 2016, 11:08 p.m., Scott Jewell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53442/
> ---
> 
> (Updated Nov. 3, 2016, 11:08 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Eric Shu.
> 
> 
> Bugs: GEODE-1740
> https://issues.apache.org/jira/browse/GEODE-1740
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1740: Correct potential region inconsistencies with concurrent clear 
> and transaction commit
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionMap.java
>  de05b0d3991254834da94ed97ada9c9247aa69ab 
>   geode-core/src/main/java/org/apache/geode/internal/cache/RegionMap.java 
> ee8a84e57b5b72cc801cd2474a51dfd0bd3083f3 
>   geode-core/src/main/java/org/apache/geode/internal/cache/TXState.java 
> 99a3b83d931dccd0faec482e42cda7ded18a13e7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ClearTXLockingDUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53442/diff/
> 
> 
> Testing
> ---
> 
> New unit test ClearTXLockingDUnitTest
> 
> precheckin
> 
> 
> Thanks,
> 
> Scott Jewell
> 
>

Re: Review Request 53355: fix deadlock caused by how the GemFireCacheImpl class synchronization is done

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On Nov. 4, 2016, 5:58 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53355/
> ---
> 
> (Updated Nov. 4, 2016, 5:58 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Scott Jewell.
> 
> 
> Bugs: GEODE-1971
> https://issues.apache.org/jira/browse/GEODE-1971
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> shutdownAll now syncs on just the class instead of "this". Since it calls 
> close which also syncs on the class it is best to get this sync done early 
> and hold it for the entire shutdown.
> Some other methods that were syncing on the class no longer do. They had not 
> reason for doing so.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  ba4f1f410cef89a276634dadecf46ac80d9c3990 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/ShutdownAllDUnitTest.java
>  1bb06f1ce1d93c801a51c1d8eb4f18ffeaa9f5cc 
> 
> Diff: https://reviews.apache.org/r/53355/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Review Request 53410: GEODE-2064 Added check for system shutdown while handlling connect exception.

[anilkumar gingade]

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

Review request for geode, Bruce Schuchardt, Darrel Schneider, Eric Shu, Scott 
Jewell, Ken Howe, and Swapnil Bawaskar.


Repository: geode


Description
---

While message send in progress, if the system gets shutdown (forced 
disconnect), the send (message delivery to peers) reports connect exception and 
ignores detecting/throwing SystemDisconnect exception. 

In "DirectChannel.getConnection()" it checks for "mgr.shutdownInProgress()" and 
returns ConnectException to the caller 
"GMSMembershipManager.directChannelSend()"

In client/server scenario, if the client is performing cache operation, the 
cache operation may succeed in server that is getting down and failure to 
deliver the message to other peers/servers. The client will see the operation 
getting successfully completed.

The above scenario could result in client missing an event and resulting in 
data mismatch between client and server.

Made changes to throw "DistributedSystemDisconnectedException" if system is 
shutting down. This will result in caller to retry the operation.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManager.java
 a4691f4 
  
geode-core/src/test/java/org/apache/geode/distributed/internal/membership/gms/mgr/GMSMembershipManagerJUnitTest.java
 bae1ddc 

Diff: https://reviews.apache.org/r/53410/diff/


Testing
---

Added new unit test. Verified the test without my change and with the change. 
With change test looks for DistributedSystemDisconnectedException to be thrown.


Thanks,

anilkumar gingade

Re: Review Request 53355: fix deadlock caused by how the GemFireCacheImpl class synchronization is done

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
(line 1755)
<https://reviews.apache.org/r/53355/#comment224232>

This changes the behavior of shutdown check.
Earlier if there is concurrent create and shutdown is in progress, the 
"isCacheAtShutdownAll" is set while create in progress, now it will be set 
after the create is completed. This will impact all the methods calling 
"isCacheAtShutdownAll".


- anilkumar gingade


On Nov. 1, 2016, 11:25 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53355/
> ---
> 
> (Updated Nov. 1, 2016, 11:25 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Scott Jewell.
> 
> 
> Bugs: GEODE-1971
> https://issues.apache.org/jira/browse/GEODE-1971
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> shutdownAll now syncs on just the class instead of "this". Since it calls 
> close which also syncs on the class it is best to get this sync done early 
> and hold it for the entire shutdown.
> Some other methods that were syncing on the class no longer do. They had not 
> reason for doing so.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  ba4f1f410cef89a276634dadecf46ac80d9c3990 
> 
> Diff: https://reviews.apache.org/r/53355/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Re: Backwards compatibility for 1.1

[Anilkumar Gingade]

Right, to be enterprise class software product, it needs to be backward
compatible...We also need to consider rolling upgrade of the system

Thanks, Dan, Bruce for the write-up and frame-work...

-Anil.


On Wed, Nov 2, 2016 at 10:37 AM, William Markito Oliveira <
william.mark...@gmail.com> wrote:

> +1
>
> On Wed, Nov 2, 2016 at 10:30 AM, Swapnil Bawaskar 
> wrote:
>
> > +1 for maintaining backwards compatibility.
> >
> > On Wed, Nov 2, 2016 at 9:40 AM, Mark Bretl  wrote:
> >
> > > +1 for backward compatibility with Geode releases.
> > >
> > > --Mark
> > >
> > > On Wed, Nov 2, 2016 at 8:11 AM, Kenneth Howe  wrote:
> > >
> > > > +1 to Dan
> > > > +1 to Bruce - the distributedTest extensions for backward
> compatibility
> > > > would great
> > > >
> > > > > On Nov 1, 2016, at 4:11 PM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > > > wrote:
> > > > >
> > > > > +1
> > > > >
> > > > > I still have the backward-compatibility distributedTest extensions
> > that
> > > > I could contribute.  The extension lets you spawn a VM running an
> older
> > > > version and interact with it.  You can even run a unit test in the
> > > spawned
> > > > VM.
> > > > >
> > > > > I have one test that sets up a server using the current version and
> > > then
> > > > spawns a client unit test running under an older version.  The client
> > > finds
> > > > the server through the distributedTest locator and runs its tests
> > against
> > > > the server.
> > > > >
> > > > >
> > > > > Le 11/1/2016 à 4:04 PM, Jianxia Chen a écrit :
> > > > >> +1
> > > > >>
> > > > >> On Tue, Nov 1, 2016 at 4:00 PM, Dan Smith 
> > wrote:
> > > > >>
> > > > >>> Hi,
> > > > >>>
> > > > >>> We made a lot of changes in 1.0 that broke compatibility with old
> > > > versions
> > > > >>> of gemfire for various reasons (package renaming, changing
> > membership
> > > > >>> system). I just wanted to confirm that starting with 1.1, we're
> > > > planning on
> > > > >>> maintaining client/server, peer-to-peer, WAN and disk backwards
> > > > >>> compatibility with older versions geode as outlined in this wiki
> > > page:
> > > > >>>
> > > > >>> https://cwiki.apache.org/confluence/display/GEODE/
> > Managing+Backward+
> > > > >>> Compatibility
> > > > >>> https://cwiki.apache.org/confluence/display/GEODE/
> > > > >>> Criteria+for+Code+Submissions
> > > > >>>
> > > > >>> Now that we have 1.0 out the door, we need to be more careful
> about
> > > > >>> introducing changes that might break compatibility if we're going
> > to
> > > > stick
> > > > >>> to these guidelines. We also probably should introduce some tests
> > > that
> > > > >>> check compatibility with 1.0.
> > > > >>>
> > > > >>>
> > > > >>> -Dan
> > > > >>>
> > > > >
> > > >
> > > >
> > >
> >
>
>
>
> --
> ~/William
>

Re: [DISCUSS] Graduation

[Anilkumar Gingade]

+1

On Fri, Oct 28, 2016 at 10:23 PM, Avinash Dongre  wrote:

> +1
>
> On Sat, Oct 29, 2016 at 8:40 AM, yang theseus 
> wrote:
>
> > +1!
> >
> > 2016-10-28 7:07 GMT+08:00 Nitin Lamba :
> >
> > > +1!
> > >
> > > On Wed, Oct 26, 2016 at 12:36 PM, Nabarun Nag  wrote:
> > >
> > > > +1
> > > > On Wed, Oct 26, 2016 at 12:07 PM Mark Bretl 
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Wed, Oct 26, 2016 at 12:04 PM, Ashvin A 
> > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Tue, Oct 25, 2016 at 5:25 PM, Roman Shaposhnik <
> r...@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > >  inactive
> > > > > > >   microsoft.com (Ashvin)
> > > > > > >
> > > > > >
> > > > > > :-(
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [97/98] [abbrv] incubator-geode git commit: GEODE-2043: change makeTombstone to handle exception

[Anilkumar Gingade]

I am seeing build failures with:

***
FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':geode-core:spotlessJavaCheck'.
> Format violations were found. Run 'gradlew spotlessApply' to fix them.

geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionEntry.java

geode-core/src/test/java/org/apache/geode/internal/cache/AbstractRegionEntryTest.java

***

Planning to commit changes after running "spotlessApply" to fix the issue...

-Anil.



On Fri, Oct 28, 2016 at 2:41 PM,  wrote:

> GEODE-2043: change makeTombstone to handle exception
>
> Now if makeTombstone has an exception but had already changed
> the region entry value to a TOMBSTONE, it will now change
> the value to REMOVE_PHASE2 instead of leaving it as a TOMBSTONE.
>
>
> Project: http://git-wip-us.apache.org/repos/asf/incubator-geode/repo
> Commit: http://git-wip-us.apache.org/repos/asf/incubator-geode/
> commit/2ef50b24
> Tree: http://git-wip-us.apache.org/repos/asf/incubator-geode/tree/2ef50b24
> Diff: http://git-wip-us.apache.org/repos/asf/incubator-geode/diff/2ef50b24
>
> Branch: refs/heads/feature/GEM-983
> Commit: 2ef50b24de1457ab91729f22a3c2ff4a8a07557b
> Parents: 765a55a
> Author: Darrel Schneider 
> Authored: Thu Oct 27 16:05:08 2016 -0700
> Committer: Darrel Schneider 
> Committed: Fri Oct 28 14:12:59 2016 -0700
>
> --
>  .../internal/cache/AbstractRegionEntry.java |  15 ++-
>  .../internal/cache/AbstractRegionEntryTest.java | 112 +++
>  2 files changed, 125 insertions(+), 2 deletions(-)
> --
>
>
> http://git-wip-us.apache.org/repos/asf/incubator-geode/
> blob/2ef50b24/geode-core/src/main/java/org/apache/geode/internal/cache/
> AbstractRegionEntry.java
> --
> diff --git 
> a/geode-core/src/main/java/org/apache/geode/internal/cache/AbstractRegionEntry.java
> b/geode-core/src/main/java/org/apache/geode/internal/
> cache/AbstractRegionEntry.java
> index 4e1f0aa..2138af9 100644
> --- a/geode-core/src/main/java/org/apache/geode/internal/
> cache/AbstractRegionEntry.java
> +++ b/geode-core/src/main/java/org/apache/geode/internal/
> cache/AbstractRegionEntry.java
> @@ -209,7 +209,7 @@ public abstract class AbstractRegionEntry implements
> RegionEntry, HashEntry  version.getRegionVersion())) {
>// distributed gc with higher vector version preempts this operation
>if (!isTombstone()) {
> -setValue(r, Token.TOMBSTONE);
> +basicMakeTombstone(r);
>  r.incTombstoneCount(1);
>}
>r.getRegionMap().removeTombstone(this, version, false, true);
> @@ -220,7 +220,7 @@ public abstract class AbstractRegionEntry implements
> RegionEntry, HashEntry}
>setRecentlyUsed();
>boolean newEntry = (getValueAsToken() == Token.REMOVED_PHASE1);
> -  setValue(r, Token.TOMBSTONE);
> +  basicMakeTombstone(r);
>r.scheduleTombstone(this, version);
>if (newEntry) {
>  // bug #46631 - entry count is decremented by scheduleTombstone
> but this is a new entry
> @@ -228,6 +228,17 @@ public abstract class AbstractRegionEntry implements
> RegionEntry, HashEntry}
>  }
>}
> +  private void basicMakeTombstone(LocalRegion r) throws
> RegionClearedException {
> +boolean setValueCompleted = false;
> +try {
> +  setValue(r, Token.TOMBSTONE);
> +  setValueCompleted = true;
> +} finally {
> +  if (!setValueCompleted && isTombstone()) {
> +removePhase2();
> +  }
> +}
> +  }
>
>
>@Override
>
> http://git-wip-us.apache.org/repos/asf/incubator-geode/
> blob/2ef50b24/geode-core/src/test/java/org/apache/geode/internal/cache/
> AbstractRegionEntryTest.java
> --
> diff --git a/geode-core/src/test/java/org/apache/geode/internal/
> cache/AbstractRegionEntryTest.java b/geode-core/src/test/java/
> org/apache/geode/internal/cache/AbstractRegionEntryTest.java
> new file mode 100644
> index 000..36e3e30
> --- /dev/null
> +++ b/geode-core/src/test/java/org/apache/geode/internal/
> cache/AbstractRegionEntryTest.java
> @@ -0,0 +1,112 @@
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements.  See the NOTICE file distributed with
> + * this work for additional information regarding copyright ownership.
> + * The ASF licenses this file to You under the Apache License, Version 2.0
> + * (the "License"); you may not use this file except in compliance with
> + * the License.  You may obtain a copy of the License at
> + *
> + *  http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed 

Re: [ANNOUNCE] Donation of Geode documentation

[Anilkumar Gingade]

I don't see any "search" option with docs? Did we miss it...

http://geode.incubator.apache.org/docs/guide/about_geode.html

-Anil.


On Thu, Sep 29, 2016 at 8:27 PM, Anthony Baker  wrote:

> I am pleased to announce the donation of Geode documentation to the
> Geode community.
>
> The documentation provides a complete user guide for Geode. This
> donation includes the source necessary to build the documentation site
> currently hosted by Pivotal [1]. The documentation source has been
> converted into a community-friendly markdown format.
>
> The Software Grant Agreement for this code has been accepted by the ASF
> secretary.
>
> The donated source currently sits in a separate branch in the Geode
> repository named staging/docs-grant1 [2] and is awaiting community
> review. I encourage everyone in the Geode community to review this
> donation and provide feedback. Once the community has reached a
> consensus we can determine next steps and how this code might get
> merged into the develop branch [3]. This will allow the geode
> community to accept documentation contributions and self-host the
> documentation on the project website. Your suggestions are most
> welcome!
>
> Thanks,
> Anthony
>
> [1] http://geode.docs.pivotal.io
> [2] https://git-wip-us.apache.org/repos/asf?p=incubator-geode.
> git;a=tree;h=refs/heads/staging/docs-grant1;hb=refs/
> heads/staging/docs-grant1
> [3] https://issues.apache.org/jira/browse/GEODE-1952
>

Re: Review Request 53071: GEODE-2021: Get on non colocated keys in a transaction does not throw TransactionDataNotColocatedException

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On Oct. 21, 2016, 5:08 p.m., Eric Shu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53071/
> ---
> 
> (Updated Oct. 21, 2016, 5:08 p.m.)
> 
> 
> Review request for geode, Darrel Schneider and Swapnil Bawaskar.
> 
> 
> Bugs: GEODE-2021
> https://issues.apache.org/jira/browse/GEODE-2021
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Throw TransactionDataNotColocatedException when get locally failed with 
> BucketNotFoundException
> Added a dunit test which passes with the fix and failed without the fix.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
>  baab79f 
>   geode-core/src/test/java/org/apache/geode/disttx/PRDistTXDUnitTest.java 
> f36085b 
>   
> geode-core/src/test/java/org/apache/geode/disttx/PRDistTXWithVersionsDUnitTest.java
>  268c2ed 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRColocationDUnitTest.java
>  1b8d2d1 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRTransactionDUnitTest.java
>  516c240 
> 
> Diff: https://reviews.apache.org/r/53071/diff/
> 
> 
> Testing
> ---
> 
> precheckin.
> 
> 
> Thanks,
> 
> Eric Shu
> 
>

Re: Review Request 52891: GEODE-538: Add check for persistent data recovery

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/org/apache/geode/cache/query/Query.java (line 92)
<https://reviews.apache.org/r/52891/#comment222410>

Wemay have to add this to other flavors of execute(*)...


- anilkumar gingade


On Oct. 17, 2016, 11:15 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52891/
> ---
> 
> (Updated Oct. 17, 2016, 11:15 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, 
> Scott Jewell, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> PartitionedRegion.getNodeForBucketReadOrLoad can return an invalid node
> if persistent data recovery is in process and a get() targets a bucket
> that
> hasn't been recoverd yet. This can result in returning an incorrect
> value (null) or throwing ConflictingPersistentDataException from a get()
> or put() on the region.
> 
> This change adds a check for persistent recovery to be completed
> before creating the new bucket. If recovery isn't complete then the
> operation on the region will fail with a PartitionOfflineException.
> 
> Queries on a region while persistent recovery is in progress can also
> result in incorrect results so a similar check is added to
> DefaultQuery.checkQueryOnPR.
> 
> New DUnit tests added for gets, puts, and queries for cases where persistent
> colocated child regions haven't been started and where the child region
> has been started but persistent recovery is still in progress when
> the region operation is attempted.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/cache/query/Query.java e27687d 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
>  58df390 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PRHARedundancyProvider.java
>  cfedb67 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
>  baab79f 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> 8bfdd68 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRBasicQueryDUnitTest.java
>  8ef907a 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryDUnitHelper.java
>  cfb4190 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/PersistentColocatedPartitionedRegionDUnitTest.java
>  0a25228 
> 
> Diff: https://reviews.apache.org/r/52891/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2

[Anilkumar Gingade]

+1 for release...

On Mon, Oct 17, 2016 at 2:54 PM, Anilkumar Gingade <aging...@pivotal.io>
wrote:

> Hi Karen,
>
> The fix still keeps the doc stating:
> "a client will need to set its credential, composed of the two properties
> `security-username` and `security-password`."
>
> What i see is, additional doc about setting the auth properties using
> callbacks
>
> Am i missing anything?
>
> -Anil.
>
>
>
>
> On Mon, Oct 17, 2016 at 1:12 PM, Karen Miller <kmil...@pivotal.io> wrote:
>
>> +0
>>
>> With GEODE-1883 being moved to a subsequent release, the just-donated docs
>> are not-quite current with respect to how a client cache may set its
>> credentials for
>> authentication.  I put in a fix for this on the develop branch:
>> https://github.com/apache/incubator-geode/commit/f1df6fc5920
>> d0d1eebd210e816e61ad44074d39d
>>
>> If there were to be a third release candidate, a cherry pick of this
>> commit
>> will correct the
>> 1.0.0-incubating documentation.
>>
>>
>>
>> On Mon, Oct 17, 2016 at 12:10 PM, Dan Smith <dsm...@pivotal.io> wrote:
>>
>> > +1
>> >
>> > Checked
>> >   * signatures
>> >   * maven repo with simple sample app
>> >   * command line test through gfsh
>> >   * built the source
>> >
>> > Checked it with this thing:
>> > https://github.com/upthewaterspout/geode-release-check
>> >
>> > On Mon, Oct 17, 2016 at 11:55 AM, William Markito <wmark...@pivotal.io>
>> > wrote:
>> >
>> > > +1
>> > >
>> > >  Checked SHA, signatures, build/run, sample app and command line
>> testing
>> > > through gfsh.
>> > >
>> > > On Mon, Oct 17, 2016 at 10:33 AM, Kirk Lund <kl...@pivotal.io> wrote:
>> > >
>> > > > +1 I think we should target GEODE-2004 and GEODE-1883 for a point
>> > release
>> > > > after 1.0.0
>> > > >
>> > > >
>> > > > On Mon, Oct 17, 2016 at 9:46 AM, Jinmei Liao <jil...@pivotal.io>
>> > wrote:
>> > > >
>> > > > > +0
>> > > > >
>> > > > > This candidate does not include the fix for GEODE-2004 and
>> > GEODE-1883.
>> > > > It's
>> > > > > not a must fix though.
>> > > > >
>> > > > > On Sun, Oct 16, 2016 at 6:58 PM, Anthony Baker <aba...@pivotal.io
>> >
>> > > > wrote:
>> > > > >
>> > > > > > +1
>> > > > > >
>> > > > > > * Verified sha’s
>> > > > > > * Verified signatures
>> > > > > > * Verified tag signature
>> > > > > > * Build and run from src distro
>> > > > > > * Checked src distro for binaries
>> > > > > > * Run some examples from mvn repo
>> > > > > > * Reviewed LICENSE and NOTICE
>> > > > > >
>> > > > > > Anthony
>> > > > > >
>> > > > > > > On Oct 15, 2016, at 5:51 PM, Swapnil Bawaskar <
>> > > sbawas...@pivotal.io>
>> > > > > > wrote:
>> > > > > > >
>> > > > > > > All,
>> > > > > > >
>> > > > > > > This is the second release candidate for Apache Geode, version
>> > > > > > > 1.0.0-incubating. I discarded the first release candidate
>> since
>> > my
>> > > > pgp
>> > > > > > > key was missing from the KEYS file.
>> > > > > > > Thanks to all the community members to drive towards this
>> > > milestone!
>> > > > > > >
>> > > > > > > It fixes the following issues:
>> > > > > > >
>> > > > > > >https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> > > > > > projectId=12318420=12332343
>> > > > > > >
>> > > > > > > *** Please download, test and vote by Wednesday, October 19,
>> 0800
>> > > hrs
>> > > > > > > US Pacific.
>> > > > > > >
>> > > > > > > Note that we are voting upon the source (tag):
>> > > > > > >   rel/1.0.0-incubating.RC2
>> > > > > > > <https://git-wip-us.apache.org/repos/asf?p=incubator-
>> > > > > > geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.RC2>
>> > > > > > >
>> > > > > > > Commit ID: 280a407c59a89401d5d87d6e6aeda1c975870753
>> > > > > > > <https://git-wip-us.apache.org/repos/asf?p=incubator-
>> > > > > > geode.git;a=commit;h=280a407c59a89401d5d87d6e6aeda1c975870753>
>> > > > > > >
>> > > > > > > Source and binary files:
>> > > > > > >   https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.
>> > > > > > 0-incubating.RC2/
>> > > > > > >
>> > > > > > > The documentation on how to install and use Apache Geode are
>> > hosted
>> > > > > > > on pivotal.io:
>> > > > > > >   http://geode.docs.pivotal.io
>> > > > > > >
>> > > > > > > Maven staging repo:
>> > > > > > >   https://repository.apache.org/content/repositories/
>> > > > > > orgapachegeode-1014/
>> > > > > > >
>> > > > > > > Geode's KEYS file containing PGP keys we use to sign the
>> release:
>> > > > > > >   https://github.com/apache/incubator-geode/blob/release/
>> > > > > > 1.0.0-incubating/KEYS
>> > > > > > >
>> > > > > > > Release Signed with Key: pub   4096R/18F902DB 2016-04-07
>> > > > > > > Fingerprint: E1B1 ABE3 4753 E7BA 8097  4285 8F8F 2BCC 18F9
>> 02DB
>> > > > > > >
>> > > > > > > Thanks,
>> > > > > > >
>> > > > > > > Swapnil.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Cheers
>> > > > >
>> > > > > Jinmei
>> > > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > >
>> > > ~/William
>> > >
>> >
>>
>
>

Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2

[Anilkumar Gingade]

Hi Karen,

The fix still keeps the doc stating:
"a client will need to set its credential, composed of the two properties
`security-username` and `security-password`."

What i see is, additional doc about setting the auth properties using
callbacks

Am i missing anything?

-Anil.




On Mon, Oct 17, 2016 at 1:12 PM, Karen Miller  wrote:

> +0
>
> With GEODE-1883 being moved to a subsequent release, the just-donated docs
> are not-quite current with respect to how a client cache may set its
> credentials for
> authentication.  I put in a fix for this on the develop branch:
> https://github.com/apache/incubator-geode/commit/
> f1df6fc5920d0d1eebd210e816e61ad44074d39d
>
> If there were to be a third release candidate, a cherry pick of this commit
> will correct the
> 1.0.0-incubating documentation.
>
>
>
> On Mon, Oct 17, 2016 at 12:10 PM, Dan Smith  wrote:
>
> > +1
> >
> > Checked
> >   * signatures
> >   * maven repo with simple sample app
> >   * command line test through gfsh
> >   * built the source
> >
> > Checked it with this thing:
> > https://github.com/upthewaterspout/geode-release-check
> >
> > On Mon, Oct 17, 2016 at 11:55 AM, William Markito 
> > wrote:
> >
> > > +1
> > >
> > >  Checked SHA, signatures, build/run, sample app and command line
> testing
> > > through gfsh.
> > >
> > > On Mon, Oct 17, 2016 at 10:33 AM, Kirk Lund  wrote:
> > >
> > > > +1 I think we should target GEODE-2004 and GEODE-1883 for a point
> > release
> > > > after 1.0.0
> > > >
> > > >
> > > > On Mon, Oct 17, 2016 at 9:46 AM, Jinmei Liao 
> > wrote:
> > > >
> > > > > +0
> > > > >
> > > > > This candidate does not include the fix for GEODE-2004 and
> > GEODE-1883.
> > > > It's
> > > > > not a must fix though.
> > > > >
> > > > > On Sun, Oct 16, 2016 at 6:58 PM, Anthony Baker 
> > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > * Verified sha’s
> > > > > > * Verified signatures
> > > > > > * Verified tag signature
> > > > > > * Build and run from src distro
> > > > > > * Checked src distro for binaries
> > > > > > * Run some examples from mvn repo
> > > > > > * Reviewed LICENSE and NOTICE
> > > > > >
> > > > > > Anthony
> > > > > >
> > > > > > > On Oct 15, 2016, at 5:51 PM, Swapnil Bawaskar <
> > > sbawas...@pivotal.io>
> > > > > > wrote:
> > > > > > >
> > > > > > > All,
> > > > > > >
> > > > > > > This is the second release candidate for Apache Geode, version
> > > > > > > 1.0.0-incubating. I discarded the first release candidate since
> > my
> > > > pgp
> > > > > > > key was missing from the KEYS file.
> > > > > > > Thanks to all the community members to drive towards this
> > > milestone!
> > > > > > >
> > > > > > > It fixes the following issues:
> > > > > > >
> > > > > > >https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > > > > projectId=12318420=12332343
> > > > > > >
> > > > > > > *** Please download, test and vote by Wednesday, October 19,
> 0800
> > > hrs
> > > > > > > US Pacific.
> > > > > > >
> > > > > > > Note that we are voting upon the source (tag):
> > > > > > >   rel/1.0.0-incubating.RC2
> > > > > > >  > > > > > geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.RC2>
> > > > > > >
> > > > > > > Commit ID: 280a407c59a89401d5d87d6e6aeda1c975870753
> > > > > > >  > > > > > geode.git;a=commit;h=280a407c59a89401d5d87d6e6aeda1c975870753>
> > > > > > >
> > > > > > > Source and binary files:
> > > > > > >   https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.
> > > > > > 0-incubating.RC2/
> > > > > > >
> > > > > > > The documentation on how to install and use Apache Geode are
> > hosted
> > > > > > > on pivotal.io:
> > > > > > >   http://geode.docs.pivotal.io
> > > > > > >
> > > > > > > Maven staging repo:
> > > > > > >   https://repository.apache.org/content/repositories/
> > > > > > orgapachegeode-1014/
> > > > > > >
> > > > > > > Geode's KEYS file containing PGP keys we use to sign the
> release:
> > > > > > >   https://github.com/apache/incubator-geode/blob/release/
> > > > > > 1.0.0-incubating/KEYS
> > > > > > >
> > > > > > > Release Signed with Key: pub   4096R/18F902DB 2016-04-07
> > > > > > > Fingerprint: E1B1 ABE3 4753 E7BA 8097  4285 8F8F 2BCC 18F9 02DB
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Swapnil.
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Cheers
> > > > >
> > > > > Jinmei
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > ~/William
> > >
> >
>

Re: Review Request 52891: GEODE-538: Add check for persistent data recovery

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
 (line 608)
<https://reviews.apache.org/r/52891/#comment222128>

We are caling this in two places...And we are trying to determine offline 
disk stores while throwing exception...Can we move this to a method in PR...And 
call that function here...
E.g.:

isPROffline() throws PartitionOfflineException () {
}



geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
 (line 611)
<https://reviews.apache.org/r/52891/#comment222127>

We need to add this exception to the javadoc for query.execute(*) (Query 
interface).


- anilkumar gingade


On Oct. 14, 2016, 10:39 p.m., Ken Howe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52891/
> ---
> 
> (Updated Oct. 14, 2016, 10:39 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Eric Shu, 
> Scott Jewell, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> PartitionedRegion.getNodeForBucketReadOrLoad can return an invalid node
> if persistent data recovery is in process and a get() targets a bucket
> that
> hasn't been recoverd yet. This can result in returning an incorrect
> value (null) or throwing ConflictingPersistentDataException from a get()
> or put() on the region.
> 
> This change adds a check for persistent recovery to be completed
> before creating the new bucket. If recovery isn't complete then the
> operation on the region will fail with a PartitionOfflineException.
> 
> Queries on a region while persistent recovery is in progress can also
> result in incorrect results so a similar check is added to
> DefaultQuery.checkQueryOnPR.
> 
> New DUnit tests added for gets, puts, and queries for cases where persistent
> colocated child regions haven't been started and where the child region
> has been started but persistent recovery is still in progress when
> the region operation is attempted.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQuery.java
>  58df3904e32b1af140bda92e0aba16da28c6a109 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PRHARedundancyProvider.java
>  cfedb677bceb884cd726f26e5bd0047876a668ab 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegion.java
>  baab79f930ab0eca03ab04660a21d10f5508f578 
>   
> geode-core/src/main/java/org/apache/geode/internal/i18n/LocalizedStrings.java 
> 8bfdd686eb50605e12cb59015d5ddab99714c563 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRBasicQueryDUnitTest.java
>  8ef907ac85195d0433f3e2f923a7a9e02fc48fff 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryDUnitHelper.java
>  cfb419036817d994ef49e4e0bcfb304d15db300e 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/PersistentColocatedPartitionedRegionDUnitTest.java
>  0a25228c9b2fd5066bbaf7f806462bcff36f0ba9 
> 
> Diff: https://reviews.apache.org/r/52891/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Ken Howe
> 
>

Re: Review Request 52619: GEODE-1967 Old key are not removed from the removedKeyValuesEntries after it was removed from Compact Range Indexes

[anilkumar gingade]

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




geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactMapRangeIndex.java
 (line 144)
<https://reviews.apache.org/r/52619/#comment220471>

Is this safe to remove entry here...The backing map looks like just hash 
map (not concurrent)...


- anilkumar gingade


On Oct. 7, 2016, 5:48 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52619/
> ---
> 
> (Updated Oct. 7, 2016, 5:48 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
> zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> CompactMapRangeIndex loses track when the same entry is deleted and added 
> because after the mapping was removed from the CompactMapRangeIndex it was 
> not removed from removedKeyValuesEntries. So when the same entry is 
> reentered, the system ends up thinking inplace modification has occured and 
> ends up removing the updated new entry, resulting in empty query results for 
> that entry.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactMapRangeIndex.java
>  234dfae 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
>  b651272 
> 
> Diff: https://reviews.apache.org/r/52619/diff/
> 
> 
> Testing
> ---
> 
> precheck 
> Additional tests were written.
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Limiting scope for Geode 1.0

[Anilkumar Gingade]

If fixing flaky tests are not in the release plan, its a good idea to move
this from release job...As you said it helps to keep the run clean and
makes it easy to track unexpected failures.

-Anil.




On Wed, Oct 5, 2016 at 2:58 PM, Swapnil Bawaskar 
wrote:

> Some of tests labeled flaky in 8929e93bd129b303aae8f9e1b13daf3c3991d1a4
> have since been fixed by Nabarun. I think we should reconcile this revision
> with Nabarun's.
>
> On Tue, Oct 4, 2016 at 12:16 PM, Anthony Baker  wrote:
>
> > I’d like merge 8929e93bd129b303aae8f9e1b13daf3c3991d1a4 to the release
> > branch.  It contains only test changes.  Sound reasonable?
> >
> > Also in that vein, what do you think about not running flakyTest in the
> > Jenkins release job [1].  That would give us a clearer picture of test
> > results and quality on the release branch.
> >
> > We should continue to run flakyTest in the nightly Jenkins job.
> >
> > Anthony
> >
> > [1] https://builds.apache.org/job/Geode-release/
> >
> >
> > > On Oct 1, 2016, at 12:30 AM, Swapnil Bawaskar 
> > wrote:
> > >
> > > Thanks for the offer Anthony,
> > > I tagged GEODE-17 / GEODE-1570 to be fixed in 1.0 and I removed the 1.0
> > tag
> > > from GEODE-1793 so that open JIRA issues for 1.0 [1] should now be
> > accurate.
> > >
> > > I have also cut a branch release/1.0.0-incubating from develop on
> commit
> > > abef045179e5d805cb04bc55a77a82798becdaae for the 1.0 release. Please
> > make
> > > sure that only issues targeted for 1.0 are fixed on that branch. If you
> > are
> > > using git flow, use git flow release track 1.0.0-incubating for
> switching
> > > to the new branch.
> > >
> > >
> > > Thanks!
> > >
> > > [1] https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20GEODE%20AND%20fixVersion%20%3D%201.0.0-incubating%
> > > 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
> > > 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >
> > > On Fri, Sep 30, 2016 at 11:30 AM, William Markito  >
> > > wrote:
> > >
> > >> +1
> > >>
> > >> On Fri, Sep 30, 2016 at 9:16 AM, Kenneth Howe 
> wrote:
> > >>
> > >>> +1
> > >>>
> >  On Sep 29, 2016, at 2:31 PM, Jacob Barrett 
> > >> wrote:
> > 
> >  +1 for creating branch now to prevent feature creep.
> > 
> >  On Thu, Sep 29, 2016 at 2:10 PM Kirk Lund  wrote:
> > 
> > > I think we should propose creating that release branch sooner
> (now?)
> > >> so
> > >>> we
> > > can minimize unplanned changes slipping into 1.0 and destabilizing
> > it.
> > >
> > > -Kirk
> > >
> > > On Thursday, September 29, 2016, Anthony Baker 
> > >>> wrote:
> > >
> > >> Using the gitflow approach, we cut a release/1.0.0 branch to
> isolate
> > >>> the
> > >> release branch from ongoing development.  For past releases we
> have
> > > waited
> > >> as long as possible to cut the branch to minimize overhead.
> Perhaps
> > >>> this
> > >> time we should create the branch earlier.
> > >>
> > >> JIRA shows the open issues for 1.0.0 [1] but there are some deltas
> > >> compared to the last release scope email [2].
> > >>
> > >> GEODE-17 / GEODE-1570 was mentioned as a possible candidate for
> > 1.0.0
> > >>> but
> > >> the Fix Version is not set
> > >> GEODE-1168 was not included in the 1.0.0 scope discussions but Fix
> > > Version
> > >> is set to 1.0.0
> > >> GEODE-1914 is follow on work from the package namespace changes
> > >>
> > >> @Swapnil, does this accurately reflect the scope discussions for
> > >> 1.0.0?
> > >> If so, I can update the bugs.
> > >>
> > >> Anthony
> > >>
> > >> [1] https://issues.apache.org/jira/issues/?jql=project%20%
> > >> 3D%20GEODE%20AND%20fixVersion%20%3D%201.0.0-incubating%
> > >> 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%
> > >> 20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >>
> > >> [2] http://mail-archives.apache.org/mod_mbox/incubator-geode-
> > >> dev/201609.mbox/%3cCANZq1gBzMTEM_JHzw2YT_
> > >>> LZeC5g472XkNCfJhma76xah=Yyq6A@
> > >> mail.gmail.com%3e
> > >>
> > >>
> > >>> On Sep 29, 2016, at 1:02 PM, Kirk Lund  > > >
> > >> wrote:
> > >>>
> > >>> What changes are we still waiting on to cut the next RC of Geode
> > >> 1.0?
> > >>>
> > >>> Is there a way to create a branch for Geode 1.0 develop that
> allows
> > > folks
> > >>> to continue working on post-1.0 features or bug fixes without
> > >> destabilizing
> > >>> Geode 1.0? This way, only the necessary changes for Geode 1.0
> would
> > >> go
> > > to
> > >>> the 1.0 branch?
> > >>>
> > >>> -Kirk
> > >>
> > >>
> > >
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >>
> > >> ~/William
> > >>
> >
> >
>

Re: Review Request 51875: GEODE-1885: Removed call to check readiness (region check) after the offheap region entry is released.

[anilkumar gingade]

> On Sept. 14, 2016, 11:20 p.m., Darrel Schneider wrote:
> >

Spoke to Darrel, he is fine with the changes as is...


- anilkumar


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


On Sept. 14, 2016, 12:22 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51875/
> ---
> 
> (Updated Sept. 14, 2016, 12:22 a.m.)
> 
> 
> Review request for geode, Darrel Schneider, Eric Shu, Ken Howe, and Swapnil 
> Bawaskar.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1885: Missing subsctiption event with Offheap partitioned region during 
> bucket rebalance.
> 
> During the trasaction commit on redundant bucket region, if the bucket region 
> is moved, the call-back logic (to deliver subscription events) were not 
> invoked due to check-readiness call with offheap region. The check-readiness 
> throws exception, if the region is not found, which causes the code to return 
> early without sending the subscription events.
> 
> In this scenario, calling check-readiness was not needed...
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractDiskRegionEntry.java
>  41cd110 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionEntry.java
>  5778a82 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionMap.java
>  81e4d9f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/ClientServerTransactionDUnitTest.java
>  08953d5 
> 
> Diff: https://reviews.apache.org/r/51875/diff/
> 
> 
> Testing
> ---
> 
> Reproduced the missing create event with the submitted test. And verified 
> with the fix.
> pre-checkin.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 51831: change EntryEventImpl code that does instanceof StoredObject checks

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On Sept. 14, 2016, 10:34 p.m., Darrel Schneider wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51831/
> ---
> 
> (Updated Sept. 14, 2016, 10:34 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and Eric Shu.
> 
> 
> Bugs: GEODE-1886
> https://issues.apache.org/jira/browse/GEODE-1886
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The EntryEventImpl code now checks the region first to see if it is 
> configured off-heap.
> If it is not it can give up early and not bother checking if it is an 
> instance of StoredObject.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/EntryEventImpl.java
>  bd7596f84a6a80e420c52e3a60df9e36e9a70ebb 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/StoredObject.java
>  47ad4e2466b2604ef843dc2fb7a8cbb3225d8a8a 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/EntryEventImplTest.java
>  bc8a64e8aebb497ec71290c645363a2aeb678e29 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/SearchLoadAndWriteProcessorTest.java
>  3e51fd9f95612bccfb96e4c68175581954af6ae4 
> 
> Diff: https://reviews.apache.org/r/51831/diff/
> 
> 
> Testing
> ---
> 
> precheckin, perf test
> 
> 
> Thanks,
> 
> Darrel Schneider
> 
>

Review Request 51875: GEODE-1885: Removed call to check readiness (region check) after the offheap region entry is released.

[anilkumar gingade]

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

Review request for geode, Darrel Schneider, Eric Shu, Ken Howe, and Swapnil 
Bawaskar.


Repository: geode


Description
---

GEODE-1885: Missing subsctiption event with Offheap partitioned region during 
bucket rebalance.

During the trasaction commit on redundant bucket region, if the bucket region 
is moved, the call-back logic (to deliver subscription events) were not invoked 
due to check-readiness call with offheap region. The check-readiness throws 
exception, if the region is not found, which causes the code to return early 
without sending the subscription events.

In this scenario, calling check-readiness was not needed...


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractDiskRegionEntry.java
 41cd110 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionEntry.java
 5778a82 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionMap.java
 81e4d9f 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/ClientServerTransactionDUnitTest.java
 08953d5 

Diff: https://reviews.apache.org/r/51875/diff/


Testing
---

Reproduced the missing create event with the submitted test. And verified with 
the fix.
pre-checkin.


Thanks,

anilkumar gingade

Re: Review Request 51010: GEODE-11 Test for Cluster Configuration changes for Lucene index.

[anilkumar gingade]

> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java,
> >  line 189
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471614#file1471614line189>
> >
> > Will this dir and clusterConfigDir get cleaned up after the test is 
> > run?  Should this use a TemporaryFolder rule or something else?
> 
> anilkumar gingade wrote:
> It uses the TemporaryFolder...yes it clears the config dir...Without this 
> i was having problem with the second test, where it was loading the cluster 
> config from previous test...
> 
> Jason Huynh wrote:
> Out of curiosity, how is the TemporaryFolder being used here?  Isn't 
> there a TemporaryFolder rule that needs to be created and used?  This looks 
> like it's just doing new File().mkdir()?
> 
> anilkumar gingade wrote:
> I followed the logic from ohter tests...
> 
> The file path is obtained from TemporaryFolder Rule, When the test ends 
> the Rule deletes the dir using the path info.
> 
>final String nodeDir = 
> this.temporaryFolder.getRoot().getCanonicalPath()
> + File.separator + vmIndex;
> File workingDir = new File(nodeDir);
> workingDir.mkdirs();
> 
> Jason Huynh wrote:
> Oh, I missed that part.  I think temporaryFolder has a method for 
> newFolder("") and newFile().

Good point...I will use the newFolder...


- anilkumar


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


On Aug. 11, 2016, 10:34 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51010/
> ---
> 
> (Updated Aug. 11, 2016, 10:34 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, Kirk 
> Lund, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added test to validate Cluster configuration support for Lucene indexes.
> 
> Added a new Rule to create Distributed System with test/custom 
> configuration...The "LocatorServerConfigurationRule" makes it easier to 
> create a Locator or cluster nodes with required configuration.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/51010/diff/
> 
> 
> Testing
> ---
> 
> Run the newly added test.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 51010: GEODE-11 Test for Cluster Configuration changes for Lucene index.

[anilkumar gingade]

> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java,
> >  line 189
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471614#file1471614line189>
> >
> > Will this dir and clusterConfigDir get cleaned up after the test is 
> > run?  Should this use a TemporaryFolder rule or something else?
> 
> anilkumar gingade wrote:
> It uses the TemporaryFolder...yes it clears the config dir...Without this 
> i was having problem with the second test, where it was loading the cluster 
> config from previous test...
> 
> Jason Huynh wrote:
> Out of curiosity, how is the TemporaryFolder being used here?  Isn't 
> there a TemporaryFolder rule that needs to be created and used?  This looks 
> like it's just doing new File().mkdir()?

I followed the logic from ohter tests...

The file path is obtained from TemporaryFolder Rule, When the test ends the 
Rule deletes the dir using the path info.

   final String nodeDir = this.temporaryFolder.getRoot().getCanonicalPath()
+ File.separator + vmIndex;
File workingDir = new File(nodeDir);
workingDir.mkdirs();


- anilkumar


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


On Aug. 11, 2016, 10:34 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51010/
> ---
> 
> (Updated Aug. 11, 2016, 10:34 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, Kirk 
> Lund, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added test to validate Cluster configuration support for Lucene indexes.
> 
> Added a new Rule to create Distributed System with test/custom 
> configuration...The "LocatorServerConfigurationRule" makes it easier to 
> create a Locator or cluster nodes with required configuration.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/51010/diff/
> 
> 
> Testing
> ---
> 
> Run the newly added test.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 51010: GEODE-11 Test for Cluster Configuration changes for Lucene index.

[anilkumar gingade]

> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> >

Jason, Thanks for the review...Good points...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 82
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line82>
> >
> > Is this method needed?

I like to keep it so that, if future there is need for any intial settings that 
can be done here...One could add it in the future, but it makes it easier 
having the method there...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 115
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line115>
> >
> > Should we limit the index here or rely on the host.getVM for which 
> > index values are valid?
> > 
> > If we do want to limit it in this rule, maybe break out 1 and 3 into 
> > constants?

We can rely on host.getVM...just need to check on vm_0 used for Locator...Will 
make that change...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 125
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line125>
> >
> > If mcast port is set... what will happen?  This checks to see if it's 
> > not set.

If set it will use the MCAST port set by the test...I need to do the same 
change with getNode() will add that...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java,
> >  line 103
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471614#file1471614line103>
> >
> > Should we seperate this test into two tests?  One for when the new node 
> > is created in the group and one for when it is out of the group?  This test 
> > is named in a way that made me think every new node was in the group and 
> > should have the index, but vm3 is outside the group and verifies it does 
> > not get an index

Good idea...I will split this...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java,
> >  line 154
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471614#file1471614line154>
> >
> > What currently happens if we have RegionShortcut.REPLICATE?  The index 
> > itself is just not created but everything else keeps on running?

I believe so..Its upto the gfsh command how we have added...


> On Aug. 11, 2016, 11:16 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java,
> >  line 189
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471614#file1471614line189>
> >
> > Will this dir and clusterConfigDir get cleaned up after the test is 
> > run?  Should this use a TemporaryFolder rule or something else?

It uses the TemporaryFolder...yes it clears the config dir...Without this i was 
having problem with the second test, where it was loading the cluster config 
from previous test...


- anilkumar


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


On Aug. 11, 2016, 10:34 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51010/
> ---
> 
> (Updated Aug. 11, 2016, 10:34 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, Kirk 
> Lund, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added test to validate Cluster configuration support for Lucene indexes.
> 
> Added a new Rule to create Distributed System with test/custom 
> configuration...The "LocatorServerConfigurationRule" makes it easier to 
> create a Locator or cluster nodes with required configuration.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/configuration/LuceneClusterConfigurationDUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/51010/diff/
> 
> 
> Testing
> ---
> 
> Run the newly added test.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 50962: GEODE-1742: Fixing synchronization of cqListeners in CqAttributesImpl

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On Aug. 10, 2016, 6:13 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50962/
> ---
> 
> (Updated Aug. 10, 2016, 6:13 p.m.)
> 
> 
> Review request for geode and anilkumar gingade.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Extracted CQAttributesImpl to it's own class, and fixed the
> synchronization of cqListeners so that we grab a snapshot of the
> listeners to check to avoid races where the listeners can change after
> we check for null.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/CqAttributesFactory.java
>  101c9e66be031be1b375150feaf410a025fd3efa 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/cq/CqAttributesImpl.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/cq/CqAttributesImplJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/50962/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 50903: GEODE-1583: Always pass the keep alive flag when destroying a connection

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On Aug. 10, 2016, 8:39 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50903/
> ---
> 
> (Updated Aug. 10, 2016, 8:39 p.m.)
> 
> 
> Review request for geode and anilkumar gingade.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The queue manager was closing connections without sending the
> CloseConnectionOp to the server. Changing the code to call close instead
> of destroy and passing the keepAlive flag along with the close. Also,
> changing the cache to set keepAlive *before* marking the cache as
> closed.
> 
> This should prevent any races where cache closure triggers the cache
> client updater to destroy connections or close them with the wrong
> keepAlive setting while the cache is being closed.
> 
> Note that I changed the default value for keepAlive in the cache and the
> pool to be true. I did this because the DurableClientNetDown test forces
> the connections to be closed without closing the cache, so it uses the default
> value, but also because I think this is probably safer for cases of abnormal
> termination that connections are closed by default with keepAlive=true until
> the cache is actually closing.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/InternalPool.java
>  fcb0ae8358a1ec2394bf74bd7929867dd5e6f77e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/PoolImpl.java
>  65a4dd13c25f5363f4d5a6bc2d4da1f7806596a0 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/QueueManagerImpl.java
>  7c9b187c6bc7ed6db64ac5670eb1daa3c594372f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
>  05bc83837032c95114da118e197c01ca2b3cd4f4 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  8deedc18491c6308cc1628e006098ec22640fe5d 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/QueueManagerJUnitTest.java
>  c2872e798cec373b6fba4a07a3ce8608cf235c37 
> 
> Diff: https://reviews.apache.org/r/50903/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating.M3 - RC7

[Anilkumar Gingade]

+1

On Mon, Aug 8, 2016 at 5:12 PM, Kirk Lund  wrote:

> +1
>
> - built and ran unit tests
> - started GFSH
> - launched Locator and Server
>
> -Kirk
>
> On Monday, August 8, 2016, Swapnil Bawaskar  wrote:
>
> > +1
> >
> > - compiled from source
> > - started a distributed system with servers from both source and binary
> > distributions
> > - exercised a sample application
> >
> > On Mon, Aug 8, 2016 at 5:00 PM, Darrel Schneider  > >
> > wrote:
> >
> > > +1
> > >
> > >
> > > On Mon, Aug 8, 2016 at 4:51 PM, Michael Stolz  > > wrote:
> > >
> > > > +1
> > > >
> > > > All indications are this attempt is correct
> > > >
> > > > --
> > > > Mike Stolz
> > > > Principal Engineer - Gemfire Product Manager
> > > > Mobile: 631-835-4771
> > > > On Aug 8, 2016 6:09 PM, "William Markito"  > > wrote:
> > > >
> > > > > Guys, I'll leave the voting open until tomorrow, but please vote so
> > we
> > > > can
> > > > > close and release M3.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > On Fri, Aug 5, 2016 at 4:24 PM, Anthony Baker  > >
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > * Verified she’s
> > > > > > * Verified signatures
> > > > > > * Verified tag signature
> > > > > > * Build from tag
> > > > > > * Build and run from src distro
> > > > > > * Checked src distro for binaries
> > > > > > * Run from binary distro
> > > > > > * Run some examples from mvn repo
> > > > > >
> > > > > > Anthony
> > > > > >
> > > > > > > On Aug 5, 2016, at 10:34 AM, Jason Huynh  > >
> > > wrote:
> > > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > - built from source distribution
> > > > > > > - started locator, server, listed members and created regions
> in
> > > gfsh
> > > > > > from
> > > > > > > binary
> > > > > > > - started locator and server from source built gfsh
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Aug 5, 2016 at 9:58 AM Dan Smith  > >
> > > wrote:
> > > > > > >
> > > > > > >> +1
> > > > > > >>
> > > > > > >> Verified
> > > > > > >> * Successful precheckin run of this release -
> > > > > > >> https://builds.apache.org/job/
> > > > > > >> Geode-release/24/  > > job/Geode-release/24/>
> > > > > > >> * Signatures
> > > > > > >> * Basic gfsh commands with binary dist
> > > > > > >> * Built from source dist
> > > > > > >> * Basic CRUD test with maven artifacts
> > > > > > >> * No jars in source dist
> > > > > > >>
> > > > > > >> -Dan
> > > > > > >>
> > > > > > >> On Thu, Aug 4, 2016 at 6:02 PM, William Markito <
> > > > wmark...@pivotal.io >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >>> All,
> > > > > > >>>
> > > > > > >>> This is the seventh release candidate Apache Geode, version
> > > > > > >>> 1.0.0-incubating.M3.
> > > > > > >>>
> > > > > > >>> We're including the feedback received in RC6 including a fix
> > > > > > >>> (83f97ceef52febf92ef7737726548aa0865c1a59) to run REST API
> > > tests.
> > > > > > >>>
> > > > > > >>> Thanks to all the community members to drive towards this
> > > > milestone!
> > > > > > >>>
> > > > > > >>> It fixes the following issues:
> > > > > > >>>   https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> > > > > > >>> projectId=12318420=12335358
> > > > > > >>>
> > > > > > >>> *** Please download, test and vote by Monday, August 8, 0800
> > hrs
> > > US
> > > > > > >>> Pacific.
> > > > > > >>>
> > > > > > >>> Note that we are voting upon the source (tag):
> > > > > > >>>   rel/v1.0.0-incubating.M3.RC7
> > > > > > >>>
> > > > > > >>> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.gi
> > > > > > >>> t;a=tag;h=refs/tags/rel/v1.0.0-incubating.M3.RC7
> > > > > > >>>  > > > > > >>> git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M3.RC7>
> > > > > > >>>
> > > > > > >>> Commit ID: 83f97ceef52febf92ef7737726548aa0865c1a59
> > > > > > >>>
> > > > > > >>> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.gi
> > > > > > >>> t;a=commit;h=83f97ceef52febf92ef7737726548aa0865c1a59
> > > > > > >>>
> > > > > > >>> Source and binary files:
> > > > > > >>> https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0
> > > > > > >>> -incubating.M3.RC7
> > > > > > >>>
> > > > > > >>> For this release the documentation on how to install and use
> > > Apache
> > > > > > Geode
> > > > > > >>> are hosted
> > > > > > >>> on pivotal.io:
> > > > > > >>>   http://geode.docs.pivotal.io
> > > > > > >>>
> > > > > > >>> Maven staging repo:
> > > > > > >>> https://repository.apache.org/content/repositories/
> > > > > orgapachegeode-1011
> > > > > > >>>
> > > > > > >>> Geode's KEYS file containing PGP keys we use to sign the
> > release:
> > > > > > >>>   https://github.com/apache/incubator-geode/blob/release/
> > > > > > >>> 

Re: Review Request 50903: GEODE-1583: Always pass the keep alive flag when destroying a connection

[anilkumar gingade]

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




geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/QueueConnectionImpl.java
 (line 90)
<https://reviews.apache.org/r/50903/#comment211302>

This is also called when the end point is crashed...Not sure if its still 
true, when a close is called on destroyed connection, it used to take long time 
(or used to hang); i believe the reason why destroy is called here...If thats 
not the case (the close doesn;t take long time) then its fine...


- anilkumar gingade


On Aug. 8, 2016, 6:02 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50903/
> ---
> 
> (Updated Aug. 8, 2016, 6:02 p.m.)
> 
> 
> Review request for geode and Barry Oglesby.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The queue manager was closing connections without sending the
> CloseConnectionOp to the server. Changing the code to call close instead
> of destroy and passing the keepAlive flag along with the close. Also,
> changing the cache to set keepAlive *before* marking the cache as
> closed.
> 
> This should prevent any races where cache closure triggers the cache
> client updater to destroy connections or close them with the wrong
> keepAlive setting while the cache is being closed.
> 
> Note that I changed the default value for keepAlive in the cache and the
> pool to be true. I did this because the DurableClientNetDown test forces
> the connections to be closed without closing the cache, so it uses the default
> value, but also because I think this is probably safer for cases of abnormal
> termination that connections are closed by default with keepAlive=true until
> the cache is actually closing.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/InternalPool.java
>  fcb0ae8358a1ec2394bf74bd7929867dd5e6f77e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/PoolImpl.java
>  65a4dd13c25f5363f4d5a6bc2d4da1f7806596a0 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/QueueConnectionImpl.java
>  40cf58b4093282dd15842e672dbd158638b24f9e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/client/internal/QueueManagerImpl.java
>  7c9b187c6bc7ed6db64ac5670eb1daa3c594372f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
>  05bc83837032c95114da118e197c01ca2b3cd4f4 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/AutoConnectionSourceImplJUnitTest.java
>  8deedc18491c6308cc1628e006098ec22640fe5d 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/QueueManagerJUnitTest.java
>  c2872e798cec373b6fba4a07a3ce8608cf235c37 
> 
> Diff: https://reviews.apache.org/r/50903/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 50538: GEODE-1619 PartitionedRegionSingleHopWithServerGroupDUnitTest.test_SingleHopWithServerGroupTwoClientServerGroup

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On July 27, 2016, 10:59 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50538/
> ---
> 
> (Updated July 27, 2016, 10:59 p.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-1619
> https://issues.apache.org/jira/browse/GEODE-1619
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> On the server side we iterate over a bucket-location map held in 
> RegionAdvisor for a partitioned region.  When this map is updated it is 
> cleared and completely repopulated but there is nothing preventing other 
> threads from reading the map while this is going on.  Consequently another 
> thread could see an empty or partially-filled collection and report the wrong 
> information to a client about where to go for a single-hop operation.
> 
> The fix is to create a new collection and replace the old collection with the 
> new, updated one.  Since the old collection is never modified I've changed it 
> from a ConcurrentHashMap to a HashMap.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketAdvisor.java
>  5fc9bb06367578035337faa30daac50e015a0b44 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/RegionAdvisor.java
>  8305a0d0cd4f126de77f99c6bd539f5bf72666f1 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/PartitionedRegionSingleHopWithServerGroupDUnitTest.java
>  3195b3512d02d12b449c4c089234f03bb2d55bf1 
> 
> Diff: https://reviews.apache.org/r/50538/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 50361: GEODE-1687: NPE during CqStatusListener method invocation.

[anilkumar gingade]

> On July 22, 2016, 10:18 p.m., Jason Huynh wrote:
> > geode-cq/src/main/java/com/gemstone/gemfire/cache/query/internal/cq/CqServiceImpl.java,
> >  line 2008
> > <https://reviews.apache.org/r/50361/diff/1/?file=1451412#file1451412line2008>
> >
> > Would it make sense to check the cq state prior to this and if it's not 
> > running to not check or send status?

We can't do this by looking at the closed state; as the CQ may have been 
registered, but stopped...Not intial state...We can do by checking on init 
state, but its not public (not returned)...Also we can't do this by using 
public APIs isRunning() and isStopped(); as isStopped() is true in either one 
of the condition, stopped or in init state... 

I think checking with proxy indicates that the proxy may not have been 
initialized at this time...


- anilkumar


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


On July 22, 2016, 10:02 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50361/
> ---
> 
> (Updated July 22, 2016, 10:02 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
> William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1687: NPE during CqStatusListener method invocation.
> 
> NPE in: CqServiceImpl.java -> invokeCqsConnected()
> Line#2011
> Pool cqPool = cQuery.getCQProxy().getPool(); 
> 
> 
> When a connection relating to CQ is established or dropped, CqStatusListner 
> is invoked to indicate connection/subscription status. This allows 
> application to handle if all the subscription connection is lost for CQs.
> 
> Looking at the code path for CqStatusListener there is a chance of NPE 
> getting thrown in CqServiceImpl.invokeCqsConnected when CQ is executed using 
> the Bridge loader interface (old way of client-server
> connection)
> 
> When a pool or bridge-loader connection is made or dropped, the code gets all 
> the CQs; checks if the CQ is registered using that connection/pool name and 
> invokes the CqStatusListner...
> 
> The code to check if CQ is using the corresponding pool:
> Pool cqPool = cQuery.getCQProxy().getPool();
> 
> If the CQ is getting executed using Bridge loader, the CqProxy for CQ is not 
> set when its constructed; its set when it gets executedDuring this time 
> the call to cQuery.getCQProxy() could throw NPE.
> 
> 
> Diffs
> -
> 
>   
> geode-cq/src/main/java/com/gemstone/gemfire/cache/query/internal/cq/CqServiceImpl.java
>  e1e158c 
> 
> Diff: https://reviews.apache.org/r/50361/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Review Request 50361: GEODE-1687: NPE during CqStatusListener method invocation.

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-1687: NPE during CqStatusListener method invocation.

NPE in: CqServiceImpl.java -> invokeCqsConnected()
Line#2011
Pool cqPool = cQuery.getCQProxy().getPool(); 


When a connection relating to CQ is established or dropped, CqStatusListner is 
invoked to indicate connection/subscription status. This allows application to 
handle if all the subscription connection is lost for CQs.

Looking at the code path for CqStatusListener there is a chance of NPE getting 
thrown in CqServiceImpl.invokeCqsConnected when CQ is executed using the Bridge 
loader interface (old way of client-server
connection)

When a pool or bridge-loader connection is made or dropped, the code gets all 
the CQs; checks if the CQ is registered using that connection/pool name and 
invokes the CqStatusListner...

The code to check if CQ is using the corresponding pool:
Pool cqPool = cQuery.getCQProxy().getPool();

If the CQ is getting executed using Bridge loader, the CqProxy for CQ is not 
set when its constructed; its set when it gets executedDuring this time the 
call to cQuery.getCQProxy() could throw NPE.


Diffs
-

  
geode-cq/src/main/java/com/gemstone/gemfire/cache/query/internal/cq/CqServiceImpl.java
 e1e158c 

Diff: https://reviews.apache.org/r/50361/diff/


Testing
---


Thanks,

anilkumar gingade

Re: Review Request 50089: GEODE-1669: Performance issue with Interest registration with impact on client side event processing

[anilkumar gingade]

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

(Updated July 19, 2016, 11:43 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
Jason Huynh, Lynn Hughes-Godfrey, Lynn Gallinat, William Markito, nabarun nag, 
Dan Smith, and xiaojian zhou.


Changes
---

Added changes based on review comments. Added new unit tests.


Repository: geode


Description
---

GEODE-1669: Performance issue with Interest registration with impact on client 
side event processing

This is in relation to internal ticket GEM-437.

The client interests are managed in "FilterProfile" class on server side. These 
are maintained using the concurrent data structures CopyOnWriteHashSet and 
CopyOnWriteHashMap...

When set of keys are registered from client, the keys are added to 
CopyOnWriteHashSet one by one (FilterProfile.registerClientInterestList()); 
Where a new HashSet is created each time when an entry is added, which could 
impact performance based on the number of keys registered.

This will have implication on the client side event processing; as the event 
processing gets blocked when a interest registration is in progress by other 
thread.

Change/Solution:

Instead of adding the keys one by one; the keys are added using addAll(). This 
avoids creating one hashset per interest key, which was making the registration 
process to take longer time.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/FilterProfile.java 
08a6484 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/FilterProfileJUnitTest.java
 5d53dd2 

Diff: https://reviews.apache.org/r/50089/diff/


Testing
---


Thanks,

anilkumar gingade

Re: Recovering large data for persisted regions

[Anilkumar Gingade]

Nilkanth,

One reasons I can think of; during recovery system may be consuming more
memory than (during the shutdown); the reason could be relating to how data
is recovered from the disk (reading krf,  drf files first, and then crf
files)...The memory may be used up by the data-structures that are reading
the disk files (before adding data to cache-region, and resource manager to
kick-in and evict). I will let the disk experts to chime in here...

Can you try reducing the eviction and critical heap percentage...say
eviction at 70% and heap at 85%

http://gemfire.docs.pivotal.io/docs-gemfire/latest/managing/disk_storage/file_names_and_extensions.html

-Anil.










On Fri, Jul 15, 2016 at 2:01 PM, Nilkanth Patel 
wrote:

> Hello,
>
> Facing issue in recovering data for persisted regions when large amount
> (more than heap) of data is persisted.
>
> brief about scenario .
>
> Creating 10 regions, lets call it R1, R2, R3, ... R10 with following
> config.
> For R1, R2, Total # of buckets = 113.
> For R3, R4, R10, #of buckets = 511.
>
> All above regions are configured with Disk persistance enabled (ASYNCH) and
> eviction action overflow to disk. like,
>
> RegionFactory<> rf =
> cache.createRegionFactory(RegionShortcut.PARTITION_PERSISTENT_OVERFLOW);
> rf.setDiskSynchronous(false) //for asynch writes.
> rf.setDiskStoreName("myDiskStore");PartitionAttributesFactory paf =
> new
> PartitionAttributesFactory().setRedundantCopies(3).paf.setTotalNumBuckets(511);
>
>
> For each server, Setting both --initial-heap and --max-heap to same, i.e
> 16gb with --eviction-heap-percentage=81 --critical-heap-percentage=90
>
> I keep the system running (puts, gets, delete) for hours to add data over
> time until i have overflowed tons of data approaching the heap size or
> more.
> Now i shutdown my cluster and then attempt to restart but it does not come
> up. It seems during this early phase of recovery (large amount of data),
> geode surpasses the critical threshold which kills it before successful
> startup.
>
> Is this observation correct and is this a known limitation...? If so any
> work around for this..?
>
> Also, Considering the above case, recovery for (1)
> ForceDisconnect--->Autoconnect case and (2) normal_shutdown-->restart case
> is a same mechanism or is there any differences?
>
> Thanks in advance,.
>
> Nilkanth.
>

Re: Review Request 50089: GEODE-1669: Performance issue with Interest registration with impact on client side event processing

[anilkumar gingade]

> On July 15, 2016, 10:26 p.m., Bruce Schuchardt wrote:
> > I'm afraid that your changes alter the return value of these methods.  
> > They're only supposed to return keys that were newly registered.  
> > CacheClientProxy checks the return value to see if it should invoke 
> > registration-listeners.  With your changes it will always think that all of 
> > the keys were newly registered and will always invoke listeners with the 
> > full set of keys.  I think you need something more like this:
> > 
> > keysRegistered = new HashSet(keys);
> > keysRegistered.removeAll(interestList.getSnapshot());
> > interestList.addAll(keys);

Myself and Barry talked about this...We thought, since its union of keys, if 
its already there it will be added to that...And invoking the listener will 
show all the events that gets added...

Your suggestion looks much better...I will make those changes...


- anilkumar


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


On July 15, 2016, 10:14 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50089/
> ---
> 
> (Updated July 15, 2016, 10:14 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
> Jason Huynh, Lynn Hughes-Godfrey, Lynn Gallinat, William Markito, nabarun 
> nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1669: Performance issue with Interest registration with impact on 
> client side event processing
> 
> This is in relation to internal ticket GEM-437.
> 
> The client interests are managed in "FilterProfile" class on server side. 
> These are maintained using the concurrent data structures CopyOnWriteHashSet 
> and CopyOnWriteHashMap...
> 
> When set of keys are registered from client, the keys are added to 
> CopyOnWriteHashSet one by one (FilterProfile.registerClientInterestList()); 
> Where a new HashSet is created each time when an entry is added, which could 
> impact performance based on the number of keys registered.
> 
> This will have implication on the client side event processing; as the event 
> processing gets blocked when a interest registration is in progress by other 
> thread.
> 
> Change/Solution:
> 
> Instead of adding the keys one by one; the keys are added using addAll(). 
> This avoids creating one hashset per interest key, which was making the 
> registration process to take longer time.
> 
> 
> Diffs
> -----
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/FilterProfile.java
>  08a6484 
> 
> Diff: https://reviews.apache.org/r/50089/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Review Request 50089: GEODE-1669: Performance issue with Interest registration with impact on client side event processing

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
Jason Huynh, Lynn Hughes-Godfrey, Lynn Gallinat, William Markito, nabarun nag, 
Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-1669: Performance issue with Interest registration with impact on client 
side event processing

This is in relation to internal ticket GEM-437.

The client interests are managed in "FilterProfile" class on server side. These 
are maintained using the concurrent data structures CopyOnWriteHashSet and 
CopyOnWriteHashMap...

When set of keys are registered from client, the keys are added to 
CopyOnWriteHashSet one by one (FilterProfile.registerClientInterestList()); 
Where a new HashSet is created each time when an entry is added, which could 
impact performance based on the number of keys registered.

This will have implication on the client side event processing; as the event 
processing gets blocked when a interest registration is in progress by other 
thread.

Change/Solution:

Instead of adding the keys one by one; the keys are added using addAll(). This 
avoids creating one hashset per interest key, which was making the registration 
process to take longer time.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/FilterProfile.java 
08a6484 

Diff: https://reviews.apache.org/r/50089/diff/


Testing
---


Thanks,

anilkumar gingade

Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating.M3

[Anilkumar Gingade]

+1 - One more milestone...

-Anil.


On Wed, Jul 13, 2016 at 10:39 AM, William Markito 
wrote:

> All,
>
> This is the first release candidate Apache Geode, version
> 1.0.0-incubating.M3.
> Thanks to all the community members to drive towards this milestone!
>
> It fixes the following issues:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12335358
>
> *** Please download, test and vote by Monday, July 18, 0800 hrs US Pacific.
>
> Note that we are voting upon the source (tag):
>rel/v1.0.0-incubating.M3.RC1
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=05e60b977799bcb5c835cc35f9af5325f2c5f600
>
> Commit ID: 05e60b977799bcb5c835cc35f9af5325f2c5f600
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=05e60b977799bcb5c835cc35f9af5325f2c5f600
>
> Source and binary files:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M3.RC1/
>
> For this release the documentation on how to install and use Apache Geode
> are hosted
> on pivotal.io:
>http://geode.docs.pivotal.io
>
> Maven staging repo:
>https://repository.apache.org/content/repositories/orgapachegeode-1005/
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>
>
> https://github.com/apache/incubator-geode/blob/release/1.0.0-incubating.M3/KEYS
>
> Release Key: pub  4096R/7AAED8BB 2016-07-13
> Fingerprint: 8E06 B711 DB13 3AE7 0CC1  ABDE 6A14 F0BC 7AAE D8BB
>
>
> Thanks,
>
> --
>
> ~/William
>

Re: Review Request 49904: GEODE-1644 ClassCastException is thrown with in queries against a map index

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On July 11, 2016, 5:13 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49904/
> ---
> 
> (Updated July 11, 2016, 5:13 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Map indexes were being passed just the key to match (for in queries), however 
> map indexes require an object[] where the first element is the key and the 
> second is the map key.
> 
> We can look into changing this so that the indexes themselves handle this key 
> extraction, but that will be for another "improvement" ticket.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/CompiledIn.java
>  71f9704 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/CompiledInDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/PdxStringQueryDUnitTest.java
>  5124d85 
> 
> Diff: https://reviews.apache.org/r/49904/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 49102: WAN Ack reader thread needs to be shut down before sending a close connection

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
 
<https://reviews.apache.org/r/49102/#comment206609>

How about adding comment about why we need to proceed even if the processor 
is stopped...This will help in future, if someone introduces the stop check 
back again...


- anilkumar gingade


On July 6, 2016, 8:42 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49102/
> ---
> 
> (Updated July 6, 2016, 8:42 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When closing a sender, the close connection message is sent on the same 
> connection that is used by the ack reader thread.  This causes an issue as 
> two threads are now reading off the same socket concurrently.  The fix is to 
> prevent this from happening but to do so, the input stream needs to be closed 
> (to free up from a socket read()).  
> The dispatcher also needs to shut down before the close connection is sent 
> out or it will spawn off another ack reader thread.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
>  ce08e8d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderEventProcessor.java
>  07a3be5 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/serial/ConcurrentSerialGatewaySenderEventProcessor.java
>  ff810ec 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
>  b178192 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>  358ffaf 
> 
> Diff: https://reviews.apache.org/r/49102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Valid characters in region names?

[Anilkumar Gingade]

Here is what GemFire docs states about region names:

http://gemfire.docs.pivotal.io/docs-gemfire/latest/basic_config/data_regions/region_naming.html

But again, we have supported other chars as part of region names...

The Query engine allows/detects region name with:  "_", “+”, “-“, “:”, “#”,
“@“, “$”.

-Anil.




On Thu, Jun 30, 2016 at 11:03 AM, Kevin Duling  wrote:

> I'm working on a bug where it is not possible to delete a region that has a
> hyphen in it.  E.g., the region was created with:
>
> create region --name=not-good --type=REPLICATE
>
> I've a solution done, but see this as an opportunity to add a test for
> other special characters.  Is there a list of valid and invalid characters
> for a region name?
>

Re: Review Request 49102: WAN Ack reader thread needs to be shut down before sending a close connection

[anilkumar gingade]

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


Ship it!




Nice to have unit test for this.

- anilkumar gingade


On June 22, 2016, 5:52 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49102/
> ---
> 
> (Updated June 22, 2016, 5:52 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When closing a sender, the close connection message is sent on the same 
> connection that is used by the ack reader thread.  This causes an issue as 
> two threads are now reading off the same socket concurrently.  The fix is to 
> prevent this from happening but to do so, the input stream needs to be closed 
> (to free up from a socket read()).  
> The dispatcher also needs to shut down before the close connection is sent 
> out or it will spawn off another ack reader thread.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
>  ce08e8d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderEventProcessor.java
>  07a3be5 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/serial/ConcurrentSerialGatewaySenderEventProcessor.java
>  ff810ec 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
>  b178192 
> 
> Diff: https://reviews.apache.org/r/49102/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 48757: GEODE-11: Cleaning up old IndexRepositoryImpls when buckets move

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManager.java
 (line 153)
<https://reviews.apache.org/r/48757/#comment204492>

Don't we need to set the newly created repo to  oldRepository, so that the 
IndexRepositories map gets updated with this.

The mutliple threads can still execute this concurrently...Will that be an 
issue?


- anilkumar gingade


On June 21, 2016, 5:40 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48757/
> ---
> 
> (Updated June 21, 2016, 5:40 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, nabarun nag, and 
> xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When a bucket is moved, we leave the IndexRepositoryImpl open. But even
> after the bucket moves back, we just dereference the old
> IndexRepositoryImpl without closing it. We should make sure we always
> invoke close on the IndexRepositoryImpl to clean up any resources the
> IndexWriter is using.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegion.java
>  95854ec2b47e82be946315ee65218fe504075b79 
>   geode-core/src/test/java/com/gemstone/gemfire/test/fake/Fakes.java 
> 323c281baaaf10bcf17c4b421b333de52f08dccd 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStats.java
>  ea1f35e57da557bcc298356f80d34165dc3d633a 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManager.java
>  25010b04cf10d6216b91a8de29b8c92ea2db34bf 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepository.java
>  fab2c2a5df17f836c29d983a41632469354d3955 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  110f85acd27a7c958357074ee0d30dccdf763567 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStatsJUnitTest.java
>  05e64afd1719f5d56b71c964756b425530f6a399 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManagerJUnitTest.java
>  ec56381bb54baa2de3921850afbb659c7ecf8fc8 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImplJUnitTest.java
>  7d3caf89b42a72dc0f8a9d934578e28cb4a95731 
> 
> Diff: https://reviews.apache.org/r/48757/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 48889: GEODE-1493: config/gemfire.properties that is shipped with the geode distribution contains user specific info

[anilkumar gingade]

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




geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfigImpl.java
 (line 283)
<https://reviews.apache.org/r/48889/#comment203845>

How is this change related to ipv6...

Currently the default config dir gets sets to current working 
directory...Does changing it to "" has any impact on that...It it has, it may 
affect existing customers/users...

The bug title talks about user specific info, are these changes 
related...Sorry i was unable to access the ticket...


- anilkumar gingade


On June 17, 2016, 11:48 p.m., Sai Boorlagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48889/
> ---
> 
> (Updated June 17, 2016, 11:48 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-1493
> https://issues.apache.org/jira/browse/GEODE-1493
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * removed code to change default mcast address based on machine
> * Made default cluster config dir is empty
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/AbstractDistributionConfig.java
>  c7eca0fcc72c93a198c31133434d141c39922d44 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/DistributionConfigImpl.java
>  b793e34ba656d1a05cb9f27d31e51c1109394698 
> 
> Diff: https://reviews.apache.org/r/48889/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sai Boorlagadda
> 
>

Re: Some proposed changes to the geode lucene search API

[Anilkumar Gingade]

+1

To be clear we are removing "search()" and replacing this with methods that
reflect the return types...

E.g: findKeys() - Returns only the region keys for matched query.
This provides applications flexibility of working with only keys or to
fetch region values as required.

-Anil.




On Mon, Jun 20, 2016 at 10:36 AM, Dan Smith  wrote:

> Hi team,
>
> The lucene integration work is still ongoing. We'd like to make a few
> changes to the API that was proposed on the wiki. The proposal is to add a
> few more methods to the LuceneQuery class to return different types of
> results:
>
> LuceneQuery {
>   Collection findKeys();
>   Collection findValues();
>   Collection> findResults();
>
>   //This is just the search method and LuceneQueryResults renamed
>   //to indicate these classes are specific to getting pages of results
>   PageableLuceneQueryResults findPages()
> }
>
> In addition, since the projection fields are not yet implemented, we'd like
> to remove LuceneQueryFactory.setProjectionFields and
> LuceneResultStruct.getProjectionField from the code. They can be added in
> when they are actually implemented.
>
> https://cwiki.apache.org/confluence/display/GEODE/Text+Search+With+Lucene
>
> -Dan
>

Re: Review Request 48865: GEODE-11: Added changes to Lucene AEQ, to propagate expiration destroy events (by setting the flag forwardExpirationDestroy()).

[anilkumar gingade]

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

(Updated June 17, 2016, 6:53 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Changes
---

For review...


Repository: geode


Description
---

GEODE-11: Added changes to Lucene AEQ, to propagate expiration destroy events 
(by setting the flag forwardExpirationDestroy()).


Diffs
-

  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 d283e29 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
 05b6990 

Diff: https://reviews.apache.org/r/48865/diff/


Testing (updated)
---

Added new test.
Running new test with and without the forwardExpirationDestroy flag.


Thanks,

anilkumar gingade

Re: update website for WAN, CQ and native client

[Anilkumar Gingade]

John is Right...WAN is more than just a replication of data...In order to
highlight and meaningful we have described this as Muti Site (WAN) Topology
in GemFire docs...

-Anil.


On Fri, Jun 17, 2016 at 11:15 AM, Swapnil Bawaskar 
wrote:

> Well, you can can replicate clusters over WAN, but as John was saying and
> as per Mike's clubhouse presentation on WAN
> , there are
> lots of different use cases that WAN opens up like Business unit
> Active/Passive, Realm manager, follow the sun pattern etc.
>
> On Fri, Jun 17, 2016 at 11:01 AM, Gregory Chase  wrote:
>
> > On Fri, Jun 17, 2016 at 10:53 AM, John Blum  wrote:
> >
> > > Hmmm, I disagree.
> > >
> > > Second, WAN is much more than Replication.  It is a topology used in
> > > Active-Active or DR architectures, or used perhaps for sending a select
> > > subset, "filtered" (possibly transformed), information, based on
> > locality,
> > > and so on.  To refer to WAN as just Replication would do it injustice
> > IMO.
> > >
> > >
> > Ok - I get you with regard to saving "replication" in the first bullet.
> > However, I would like a more descriptive word than "WAN" for the latter
> new
> > feature.  How about "WAN-replication" or "Cluster Replication"?
> >
> > --
> > Greg Chase
> >
> > Global Head, Big Data Communities
> > http://www.pivotal.io/big-data
> >
> > Pivotal Software
> > http://www.pivotal.io/
> >
> > 650-215-0477
> > @GregChase
> > Blog: http://geekmarketing.biz/
> >
>

Review Request 48865: GEODE-11: Added changes to Lucene AEQ, to propagate expiration destroy events (by setting the flag forwardExpirationDestroy()).

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-11: Added changes to Lucene AEQ, to propagate expiration destroy events 
(by setting the flag forwardExpirationDestroy()).


Diffs
-

  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 d283e29 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
 05b6990 

Diff: https://reviews.apache.org/r/48865/diff/


Testing
---

Running new test with and without the forwardExpirationDestroy flag.


Thanks,

anilkumar gingade

Re: Review Request 48757: GEODE-11: Cleaning up old IndexRepositoryImpls when buckets move

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManager.java
 (line 139)
<https://reviews.apache.org/r/48757/#comment203083>

Synchronization...To avoid multiple threads creating the repo.


- anilkumar gingade


On June 15, 2016, 9:36 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48757/
> ---
> 
> (Updated June 15, 2016, 9:36 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, nabarun nag, and 
> xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When a bucket is moved, we leave the IndexRepositoryImpl open. But even
> after the bucket moves back, we just dereference the old
> IndexRepositoryImpl without closing it. We should make sure we always
> invoke close on the IndexRepositoryImpl to clean up any resources the
> IndexWriter is using.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegion.java
>  95854ec2b47e82be946315ee65218fe504075b79 
>   geode-core/src/test/java/com/gemstone/gemfire/test/fake/Fakes.java 
> 323c281baaaf10bcf17c4b421b333de52f08dccd 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStats.java
>  ea1f35e57da557bcc298356f80d34165dc3d633a 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManager.java
>  25010b04cf10d6216b91a8de29b8c92ea2db34bf 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepository.java
>  fab2c2a5df17f836c29d983a41632469354d3955 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  110f85acd27a7c958357074ee0d30dccdf763567 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStatsJUnitTest.java
>  05e64afd1719f5d56b71c964756b425530f6a399 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManagerJUnitTest.java
>  ec56381bb54baa2de3921850afbb659c7ecf8fc8 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImplJUnitTest.java
>  7d3caf89b42a72dc0f8a9d934578e28cb4a95731 
> 
> Diff: https://reviews.apache.org/r/48757/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 48738: GEODE-1209 Changes to ignoreEvictionAndExpiration AEQ attribute based on the new proposal (changing ignoreEvictionAndExpiration to forwardExpirationDestroy)

[anilkumar gingade]

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

(Updated June 15, 2016, 5:42 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, Jens Deppe, William Markito, nabarun nag, Dan Smith, and xiaojian 
zhou.


Summary (updated)
-

GEODE-1209 Changes to ignoreEvictionAndExpiration AEQ attribute based on the 
new proposal (changing ignoreEvictionAndExpiration to forwardExpirationDestroy)


Repository: geode


Description
---

GEODE-1209 was proposed to add new attribute ignoreEvictionAndExpiration to 
AsyncEventQueue...As mentioned in the ticket due to product issue a new 
proposal was made to change the functionality, to only forward 
expiration-destroy operation.

The changes made here replaces ignoreEvictionAndExpiration attribute to 
forwardExiprationDestroy.


Diffs
-

  
geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
 93cb31a 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueue.java
 edf887b 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueFactory.java
 6294dfe 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
 1ec3ba0 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueImpl.java
 5a0b370 
  geode-core/src/main/java/com/gemstone/gemfire/cache/wan/GatewaySender.java 
d559a1a 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java
 7e2a0af 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderAttributes.java
 163943f 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/AsyncEventQueueCreation.java
 e55ec3f 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXml.java
 4ee3585 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlGenerator.java
 17076db 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlParser.java
 76ab0f9 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommands.java
 d84959f 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/AsyncEventQueueFunctionArgs.java
 2066628 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/CreateAsyncEventQueueFunction.java
 32e8f83 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
 cc80de8 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/QueueCommandsController.java
 9367612 
  
geode-core/src/main/resources/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd
 688ff1f 
  
geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 4c5944b 
  
geode-core/src/test/java/com/gemstone/gemfire/cache30/CacheXmlGeode10DUnitTest.java
 be4c657 
  
geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommandsDUnitTest.java
 c1877fe 
  
geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
 3c0d388 

Diff: https://reviews.apache.org/r/48738/diff/


Testing
---

- Test for ignoreEvictionAndExpiration was changeg to test 
forwardExpirationDestroy
- SharedConfigurationEndToEndDUnitTest
- CacheXmlGeode10DUnitTest
- QueueCommandsDUnitTest


Thanks,

anilkumar gingade

Review Request 48738: GEODE-1209 Changes to ignoreEvictionAndExpiration AEQ attribute based on the new proposal (chagning ignoreEvictionAndExpiration to forwardExpirationDestroy)

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, Jens Deppe, William Markito, nabarun nag, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

GEODE-1209 was proposed to add new attribute ignoreEvictionAndExpiration to 
AsyncEventQueue...As mentioned in the ticket due to product issue a new 
proposal was made to change the functionality, to only forward 
expiration-destroy operation.

The changes made here replaces ignoreEvictionAndExpiration attribute to 
forwardExiprationDestroy.


Diffs
-

  
geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
 93cb31a 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueue.java
 edf887b 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueFactory.java
 6294dfe 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
 1ec3ba0 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueImpl.java
 5a0b370 
  geode-core/src/main/java/com/gemstone/gemfire/cache/wan/GatewaySender.java 
d559a1a 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java
 7e2a0af 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderAttributes.java
 163943f 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/AsyncEventQueueCreation.java
 e55ec3f 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXml.java
 4ee3585 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlGenerator.java
 17076db 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlParser.java
 76ab0f9 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommands.java
 d84959f 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/AsyncEventQueueFunctionArgs.java
 2066628 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/CreateAsyncEventQueueFunction.java
 32e8f83 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
 cc80de8 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/QueueCommandsController.java
 9367612 
  
geode-core/src/main/resources/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd
 688ff1f 
  
geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 4c5944b 
  
geode-core/src/test/java/com/gemstone/gemfire/cache30/CacheXmlGeode10DUnitTest.java
 be4c657 
  
geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommandsDUnitTest.java
 c1877fe 
  
geode-core/src/test/resources/com/gemstone/gemfire/management/internal/cli/commands/golden-help-offline.properties
 3c0d388 

Diff: https://reviews.apache.org/r/48738/diff/


Testing
---

- Test for ignoreEvictionAndExpiration was changeg to test 
forwardExpirationDestroy
- SharedConfigurationEndToEndDUnitTest
- CacheXmlGeode10DUnitTest
- QueueCommandsDUnitTest


Thanks,

anilkumar gingade

Re: Review Request 48432: GEODE-1494: Allowing stats to be measured with callbacks

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/com/gemstone/gemfire/Statistics.java (line 453)
<https://reviews.apache.org/r/48432/#comment202192>

Good point...



geode-core/src/main/java/com/gemstone/gemfire/Statistics.java (line 517)
<https://reviews.apache.org/r/48432/#comment202194>

missing @param descriptor



geode-core/src/main/java/com/gemstone/gemfire/Statistics.java (line 533)
<https://reviews.apache.org/r/48432/#comment202195>

longerval?



geode-core/src/main/java/com/gemstone/gemfire/Statistics.java (line 615)
<https://reviews.apache.org/r/48432/#comment202196>

doubleerval?



geode-core/src/main/java/com/gemstone/gemfire/internal/HostStatSampler.java 
(line 55)
<https://reviews.apache.org/r/48432/#comment202197>

Is it intentional...We are chaging this from 3 to 30 secs? If its required 
we may need to document this and let support know about this...



geode-core/src/main/java/com/gemstone/gemfire/internal/StatSamplerStats.java 
(line 69)
<https://reviews.apache.org/r/48432/#comment202199>

    Good one...


- anilkumar gingade


On June 9, 2016, 6:41 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48432/
> ---
> 
> (Updated June 9, 2016, 6:41 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Darrel Schneider, Jason Huynh, 
> Jinmei Liao, Kirk Lund, and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding support to measure statistics with suppliers that are sampled
> every sample interval. The suppliers are invoked in a separate thread
> than the stat sampler so that slow suppliers won't screw up all stats.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/com/gemstone/gemfire/Statistics.java 
> d7f45a50af7ce58e0d65bfd6300821b36864cc9b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/DummyStatisticsImpl.java
>  83d40559ba652474630d04758696f2e9042910e7 
>   geode-core/src/main/java/com/gemstone/gemfire/internal/HostStatSampler.java 
> ebb4177c12f6d67ef2cafb76d7a3d765fb1139ea 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/StatSamplerStats.java 
> c70247939a50392e62e264bfb783a37c93a969ae 
>   geode-core/src/main/java/com/gemstone/gemfire/internal/StatisticsImpl.java 
> 2344d9315ca8b2b31e9eba35a350eca44a9b8bec 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/StatisticsTypeImpl.java
>  2a29d46dfc260a40b018af5530a4f1e781e72274 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/statistics/CallbackSampler.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/statistics/SampleCollector.java
>  dfb502bb0aa018a11ab26b10a35da2c5be7c10ac 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/LocalStatisticsImplJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/StatArchiveWriterReaderJUnitTest.java
>  bb15ff2ce747a37d87c95931d5e07cbce4ca7be6 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/StatSamplerJUnitTest.java
>  f2946b619c6272539ba00f10a9fb1444cc095231 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/statistics/CallbackSamplerJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/statistics/DummyStatistics.java
>  a1ea030443f096ba8f0bd8d5fb62a8183f20bcfd 
> 
> Diff: https://reviews.apache.org/r/48432/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 48525: GEODE-1422: Removing check to skip enqueuing temp events

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
 (line 112)
<https://reviews.apache.org/r/48525/#comment202191>

Something may be wrong with our IDE formatters, they are adding spaces with 
new line...I did see this with my eclipse IDE...


- anilkumar gingade


On June 10, 2016, 12:03 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48525/
> ---
> 
> (Updated June 10, 2016, 12:03 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This check was performed outside of synchronizing on the lock, which
> means that some events could be added to the temp events after the
> check. This caused the test to fail due to temp events being left in the
> map.
> 
> Also, fixing two race conditions in 
> testParallelPropagationSenderStartAfterStop_Scenario2
> 
> 1) It did some puts and stopped the sender without waiting for the
> puts to complete. So they may not be available on the remote side
> 
> 2) It started some puts asynchronously, and then started the sender
> later. The puts performed before the sender started may not be present
> on the remote side.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/ParallelAsyncEventQueueImpl.java
>  aa3e71cb222a610f7caf297e8c1990778da40c94 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderImpl.java
>  fa21b18e8de2a500130a4cb7f179b82b7da681e0 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderOperationsDUnitTest.java
>  3f0329a21a92ca7902a3fdaaf6ad0e0b4ef59224 
> 
> Diff: https://reviews.apache.org/r/48525/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: add 'ZeroCopy' functions into geode

[Anilkumar Gingade]

As i know we try to avoid copying as much as possibleWhen we read from
socket to storing in cache...Its mostly the reference pointer that is
passed around...Someone can correct me if i am wrong

I am interested to see how adopting techniques to reduce cache-miss rates
(L1/L2) will help Geode...

-Anil.






On Thu, Jun 9, 2016 at 12:51 PM, Swapnil Bawaskar 
wrote:

> In Geode latest data is in memory and the least recently used data can be
> overflowed to disk. Since data coming in from the sockets is the latest
> data which needs to kept in memory, I don't think zero copy will be
> helpful. On the other hand, when there is a read request for data already
> overflown to disk, we could use zero copy to write directly from disk to
> the socket.
>
> I think we could make storing data in "off-heap" work while inserting data;
> provided there are no callbacks to be invoked.
>
> On Wed, Jun 8, 2016 at 6:50 PM, theseusyang  wrote:
>
> > Hi All,
> >
> > Because when Geode continue writing Entry into cache , then frequently
> > switching Cache Context to Disk File Context, it seriously affect
> > performance , cause high-latency response.
> >
> > Maybe 'Zero Copy' is a referenced solutions, Any body is interested in
> this
> > feature?
> >
> >
> > theseus yang
> >
> >
> >
> > --
> > View this message in context:
> >
> http://apache-geode-incubating-developers-forum.70738.x6.nabble.com/add-ZeroCopy-functions-into-geode-tp6513.html
> > Sent from the Apache Geode (Incubating) Developers Forum mailing list
> > archive at Nabble.com.
> >
>

Re: Review Request 48431: GEODE-1494: Changing stats list to be a CopyOnWriteArrayList

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/com/gemstone/gemfire/internal/GemFireStatSampler.java 
(line 279)
<https://reviews.apache.org/r/48431/#comment201765>

Looks like these methods (which gets the stats from 
InternalDistributerdMember) to be defined in the StatsManager (whihc holds 
reference to the all the stats)...
Again, as we talked in our meeting, these are legacy code refactoring...We 
need to do it step by step :)


- anilkumar gingade


On June 8, 2016, 6:06 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48431/
> ---
> 
> (Updated June 8, 2016, 6:06 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Jinmei Liao, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The statsList used to track Statistics in InternalDistributedSystem was
> managed under a lock. That was problematic, because code that iterates
> on the list needs to hold the lock. If the code invoking callbacks for
> GEODE-1494 was slow, that means the lock would block other stats
> operations.
> 
> Changing this list to a copy on write array list to holding a lock for a
> long period of time.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/InternalDistributedSystem.java
>  af81cc1b770bd323f3977a865ee3280a55146b3c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/AbstractStatisticsFactory.java
>  886258b0589fd291411d11425b9a06713142a384 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/GemFireStatSampler.java
>  59305066429c0bb020b7795afec1bfdf260d08b5 
>   geode-core/src/main/java/com/gemstone/gemfire/internal/HostStatSampler.java 
> ebb4177c12f6d67ef2cafb76d7a3d765fb1139ea 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/control/HeapMemoryMonitor.java
>  90a26cbada03ea49cd769c83c9538eb7654466ed 
> 
> Diff: https://reviews.apache.org/r/48431/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: new wiki content

[Anilkumar Gingade]

Agree with Dan, its more about troubleshooting/fixing issue.

Will it be a good idea to organize them as:

Troubleshooting:
- When system encounters OOM
- When critical heap...

When i read it as design, i was expecting, system design instruction based
on certain requirement. Just my thoughts...
E.g.: For 10GB of data store, what is the memory requirement for 3 node
system...

-Anil.







On Tue, Jun 7, 2016 at 2:17 PM, Dan Smith  wrote:

> Nice, a bunch of good information here! Maybe these pages should move under
> Application Development->Troubleshooting?
>
> I think the OOME thrown page needs some work. I don't think there is such a
> thing a system that is designed such that an OOME doesn't matter. The
> system should be designed such that it doesn't run out of memory. If you
> see a member die with an OOME, then that probably requires more action than
> just restarting the member - you need to figure out why it ran out of
> memory and try to address the problem.
>
> In the Critical Heap Exceeded page, it says this: "With operations not
> completing, the system may revoke the membership of the member that
> is above the critical-heap-percentage. " I wasn't aware that there is
> anything to kick out members with critical heap. Can you clarify under what
> conditions members will be kicked out instead of throwing a
> LowMemoryException?
>
> -Dan
>
> On Tue, Jun 7, 2016 at 1:19 PM, Karen Miller  wrote:
>
> > Feedback and suggestions welcomed on a newly added Apache Geode
> > (incubating) wiki subject at
> >   https://cwiki.apache.org/confluence/display/GEODE/Index
> > The content is under the new category of Handling User Issues and Design.
> >
> > The first subject addressed is that of heap memory space and what happens
> > when a Geode
> > member exceeds threshold values in its heap allocation.
> >
> > This content targets users designing with Geode, aiming to expand into
> > that elusive target of best practices in design.
> >
> >
> >
> >
>

Re: Review Request 48188: GEODE-1495: Changes are made to remove the cached destroyed token/events from the CQ.

[anilkumar gingade]

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

(Updated June 6, 2016, 8:26 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Changes
---

Addressed NPE with CacheProfile (cf.filterProfile) found during testing.


Repository: geode


Description
---

The CQEvents as seen by CQs are cached in order to avoid applying CQ queries on 
old values.

In case of a destory CQEvent, the CQEvents are marked with destroy tokens and 
removed from
the cache after the CQEvent is added to HAQueue.
This works fine for the CQs registered locally, but for the CQs registered on 
peer server, the
CQs weren't removed from the cache, which resulted in generating wrong CQEvent 
for subsequent
operation.
This change removes the destroy CQevent from the cache after the CQEvent is 
distributed to
peer server.


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
 6a7b4f2 
  
geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/PrCqUsingPoolDUnitTest.java
 ee8ea9f 

Diff: https://reviews.apache.org/r/48188/diff/


Testing
---

Reproduce the issue with manual testing. The test passed after the changes are 
made to remove cached destroy events from remote CQs.


Thanks,

anilkumar gingade

Re: Review Request 48188: GEODE-1495: Changes are made to remove the cached destroyed token/events from the CQ.

[anilkumar gingade]

> On June 3, 2016, 10:10 p.m., Dan Smith wrote:
> > I think there should be a test with these changes.

Dan, I am adding that...Wanted to get early feedback on this and get tests 
started...
I will add the test changes to this review post.


- anilkumar


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


On June 3, 2016, 12:49 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48188/
> ---
> 
> (Updated June 3, 2016, 12:49 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
> Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The CQEvents as seen by CQs are cached in order to avoid applying CQ queries 
> on old values.
> 
> In case of a destory CQEvent, the CQEvents are marked with destroy tokens and 
> removed from
> the cache after the CQEvent is added to HAQueue.
> This works fine for the CQs registered locally, but for the CQs registered on 
> peer server, the
> CQs weren't removed from the cache, which resulted in generating wrong 
> CQEvent for subsequent
> operation.
> This change removes the destroy CQevent from the cache after the CQEvent is 
> distributed to
> peer server.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
>  6a7b4f2 
> 
> Diff: https://reviews.apache.org/r/48188/diff/
> 
> 
> Testing
> ---
> 
> Reproduce the issue with manual testing. The test passed after the changes 
> are made to remove cached destroy events from remote CQs.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 48188: GEODE-1495: Changes are made to remove the cached destroyed token/events from the CQ.

[anilkumar gingade]

> On June 3, 2016, 10:05 p.m., Bruce Schuchardt wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java,
> >  line 696
> > <https://reviews.apache.org/r/48188/diff/1/?file=1405413#file1405413line696>
> >
> > You're missing braces on all of your two-line "if" statements.

Will add the comments.


> On June 3, 2016, 10:05 p.m., Bruce Schuchardt wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java,
> >  line 693
> > <https://reviews.apache.org/r/48188/diff/1/?file=1405413#file1405413line693>
> >
> > I wonder if there isn't a better home for this method than 
> > DistributedCacheOperation?

I felt the same way; but come across the right place to add this...The logic 
needed to be added after the event is processed and sent across...


Some of the option i thought:

1. Using CacheClientNotifier where this is done for local CQs. But in this case 
(peer node) there may not be CacheClientNotifier...


- anilkumar


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


On June 3, 2016, 12:49 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48188/
> -------
> 
> (Updated June 3, 2016, 12:49 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
> Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The CQEvents as seen by CQs are cached in order to avoid applying CQ queries 
> on old values.
> 
> In case of a destory CQEvent, the CQEvents are marked with destroy tokens and 
> removed from
> the cache after the CQEvent is added to HAQueue.
> This works fine for the CQs registered locally, but for the CQs registered on 
> peer server, the
> CQs weren't removed from the cache, which resulted in generating wrong 
> CQEvent for subsequent
> operation.
> This change removes the destroy CQevent from the cache after the CQEvent is 
> distributed to
> peer server.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
>  6a7b4f2 
> 
> Diff: https://reviews.apache.org/r/48188/diff/
> 
> 
> Testing
> ---
> 
> Reproduce the issue with manual testing. The test passed after the changes 
> are made to remove cached destroy events from remote CQs.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Yes...Jason, thanks for correction...

[corrected]
I will wait for other feedbacks/comments, if there is no objection i
will change
it to "forwardExpirationDestroy" with default value set to false.

-Anil.



On Fri, Jun 3, 2016 at 12:01 PM, Jason Huynh <jhu...@pivotal.io> wrote:

> *I will wait for other feedbacks/comments, if there is no objection i
> willchange it to "forwardExpirationDestroy" with default value set to
> true.*
>
> think you meant to say default value to set false :-)
>
> On Fri, Jun 3, 2016 at 11:47 AM, Anilkumar Gingade <aging...@pivotal.io>
> wrote:
>
> > Thanks Darrel...
> >
> > The name change was based on the review comments:
> > https://reviews.apache.org/r/46243/
> >
> > I am fine with either one, ignoreXXX or forwardXXX.
> >
> > I will wait for other feedbacks/comments, if there is no objection i will
> > change it to "forwardExpirationDestroy" with default value set to true.
> >
> > Thanks,
> > -Anil.
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, Jun 2, 2016 at 2:14 PM, Darrel Schneider <dschnei...@pivotal.io>
> > wrote:
> >
> > > When did forwardXXX become ignoreXXX? I read through the email thread
> and
> > > couldn't find why that happened. It is best for the default on a
> boolean
> > > property to be false. That was the case when it was forwardXXX. But now
> > > that it has changed to ignoreXXX the default has become true. I'd vote
> > for
> > > it being named something whose default can be false.
> > >
> > >
> > > On Thu, Jun 2, 2016 at 11:10 AM, Anilkumar Gingade <
> aging...@pivotal.io>
> > > wrote:
> > >
> > > > Hi Team,
> > > >
> > > > As proposed here, we added support to propagate eviction and
> expiration
> > > > (destroy) operation to AsyncEventQueue using single flag/attribute
> > > > "ignoreEvictionAndExpiration" by default which is true (to keep the
> > same
> > > > behavior) and one could set (false) to receive eviction/expiration
> > > event...
> > > >
> > > > But we come across a product issue, GEODE-1472, that cause data
> > > > inconsistency (with eviction destroy)For this reason we are
> > planning
> > > to
> > > > break the "ignoreEvictionAndExpiration" attribute to eviction and
> > > > expiration specific:
> > > > "ignoreEvictionDestroy", "ignoreExpirationDestroy"...
> > > >
> > > > Currently we are planning to support "ignoreExpirationDestroy",  and
> > add
> > > > "ignoreEvictionDestroy" once GEODE-1472 is fixed...
> > > >
> > > > Looking for comments on this...
> > > >
> > > > Thanks,
> > > > -Anil.
> > > >
> > > > https://issues.apache.org/jira/browse/GEODE-1472
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Apr 12, 2016 at 6:04 PM, Anilkumar Gingade <
> > aging...@pivotal.io>
> > > > wrote:
> > > >
> > > > > Kirk, We could not think of any such requirement...And with this
> > > > > application will get all the update operation and can take
> > appropriate
> > > > > action (use or ignore)...
> > > > >
> > > > > -Anil.
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Apr 12, 2016 at 5:46 PM, Kirk Lund <kl...@pivotal.io>
> wrote:
> > > > >
> > > > >> Would any user ever have a reason to enable forwarding of one type
> > but
> > > > not
> > > > >> the other? If so then I would separate them as
> > forwardEvictionEvents()
> > > > and
> > > > >> forwardExpirationEvents().
> > > > >>
> > > > >>
> > > > >> On Tue, Apr 12, 2016 at 5:44 PM, Kirk Lund <kl...@pivotal.io>
> > wrote:
> > > > >>
> > > > >> > +1 for being more explicit with the "And" conjunction
> > > > >> >
> > > > >> > -Kirk
> > > > >> >
> > > > >> >
> > > > >> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker <
> aba...@pivotal.io
> > >
> > > > >> wrote:
> > > > >> >
> > > > >> >> I’d prefer to insert a conjunction to clarify the meaning:
> > > > >> >>
> > > > >> >> forwardEvictionAndExpirationEvents()
> > > > >> >>
> > > > >> >>
> > > > >> >> $0.02,
> > > > >> >> Anthony
> > > > >> >>
> > > > >> >> On Apr 12, 2016, at 5:11 PM, Anilkumar Gingade <
> > > aging...@pivotal.io>
> > > > >> >> wrote:
> > > > >> >>
> > > > >> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any
> > alternate
> > > > >> >> names?).
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>

Re: Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Thanks Darrel...

The name change was based on the review comments:
https://reviews.apache.org/r/46243/

I am fine with either one, ignoreXXX or forwardXXX.

I will wait for other feedbacks/comments, if there is no objection i will
change it to "forwardExpirationDestroy" with default value set to true.

Thanks,
-Anil.








On Thu, Jun 2, 2016 at 2:14 PM, Darrel Schneider <dschnei...@pivotal.io>
wrote:

> When did forwardXXX become ignoreXXX? I read through the email thread and
> couldn't find why that happened. It is best for the default on a boolean
> property to be false. That was the case when it was forwardXXX. But now
> that it has changed to ignoreXXX the default has become true. I'd vote for
> it being named something whose default can be false.
>
>
> On Thu, Jun 2, 2016 at 11:10 AM, Anilkumar Gingade <aging...@pivotal.io>
> wrote:
>
> > Hi Team,
> >
> > As proposed here, we added support to propagate eviction and expiration
> > (destroy) operation to AsyncEventQueue using single flag/attribute
> > "ignoreEvictionAndExpiration" by default which is true (to keep the same
> > behavior) and one could set (false) to receive eviction/expiration
> event...
> >
> > But we come across a product issue, GEODE-1472, that cause data
> > inconsistency (with eviction destroy)For this reason we are planning
> to
> > break the "ignoreEvictionAndExpiration" attribute to eviction and
> > expiration specific:
> > "ignoreEvictionDestroy", "ignoreExpirationDestroy"...
> >
> > Currently we are planning to support "ignoreExpirationDestroy",  and add
> > "ignoreEvictionDestroy" once GEODE-1472 is fixed...
> >
> > Looking for comments on this...
> >
> > Thanks,
> > -Anil.
> >
> > https://issues.apache.org/jira/browse/GEODE-1472
> >
> >
> >
> >
> > On Tue, Apr 12, 2016 at 6:04 PM, Anilkumar Gingade <aging...@pivotal.io>
> > wrote:
> >
> > > Kirk, We could not think of any such requirement...And with this
> > > application will get all the update operation and can take appropriate
> > > action (use or ignore)...
> > >
> > > -Anil.
> > >
> > >
> > >
> > > On Tue, Apr 12, 2016 at 5:46 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > >
> > >> Would any user ever have a reason to enable forwarding of one type but
> > not
> > >> the other? If so then I would separate them as forwardEvictionEvents()
> > and
> > >> forwardExpirationEvents().
> > >>
> > >>
> > >> On Tue, Apr 12, 2016 at 5:44 PM, Kirk Lund <kl...@pivotal.io> wrote:
> > >>
> > >> > +1 for being more explicit with the "And" conjunction
> > >> >
> > >> > -Kirk
> > >> >
> > >> >
> > >> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker <aba...@pivotal.io>
> > >> wrote:
> > >> >
> > >> >> I’d prefer to insert a conjunction to clarify the meaning:
> > >> >>
> > >> >> forwardEvictionAndExpirationEvents()
> > >> >>
> > >> >>
> > >> >> $0.02,
> > >> >> Anthony
> > >> >>
> > >> >> On Apr 12, 2016, at 5:11 PM, Anilkumar Gingade <
> aging...@pivotal.io>
> > >> >> wrote:
> > >> >>
> > >> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any alternate
> > >> >> names?).
> > >> >>
> > >> >>
> > >> >>
> > >> >
> > >>
> > >
> > >
> >
>

Re: build error with development branch...

[Anilkumar Gingade]

Devs, Thanks for the help and pointers...

-Anil.


On Thu, Jun 2, 2016 at 2:49 PM, Udo Kohlmeyer <ukohlme...@pivotal.io> wrote:

> Maybe try 1.8.0_92... I know it works
>
>
> On 3/06/2016 7:47 am, Dan Smith wrote:
>
>> Hmm, does that -ea mean it's an early access build? I would recommend
>> running with a later version of java 8.
>>
>> -Dan
>>
>> On Thu, Jun 2, 2016 at 2:41 PM, Anilkumar Gingade <aging...@pivotal.io>
>> wrote:
>>
>> If gradle is using the java installed/set in my environment, then it is:
>>>
>>> java version "1.8.0_20-ea"
>>> Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
>>> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)
>>>
>>> I could not see any build output that printed java version it used (nice
>>> to
>>> have, if its not there)...
>>>
>>> -Anil.
>>>
>>>
>>>
>>> On Thu, Jun 2, 2016 at 2:14 PM, Dan Smith <dsm...@pivotal.io> wrote:
>>>
>>> Develop builds for me. And travis seems happy -
>>>> https://travis-ci.org/apache/incubator-geode
>>>>
>>>> But this is actually pretty weird. In Intellij at least, it thinks that
>>>> lambda maps to a SerializableCallable even though it doesn't return a
>>>> value. I think maybe that's due to the while(true) part. If I comment
>>>>
>>> that
>>>
>>>> out, it maps to a runnable. It seems like this particular lambda
>>>> actually
>>>> *is* ambiguous since it will never return normally, it could be either a
>>>> callable or a runnable.
>>>>
>>>> What JDK and what revision are you building with? Maybe some newer JDK
>>>> is
>>>> complaining about this?
>>>>
>>>> -Dan
>>>>
>>>> -Dan
>>>>
>>>> On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade <aging...@pivotal.io>
>>>> wrote:
>>>>
>>>> Hi Devs,
>>>>>
>>>>> Anyone seeing this issue:
>>>>>
>>>>>
>>>>>
>>>>>
>>> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
>>>
>>>> error: reference to invokeAsync is ambiguous
>>>>>
>>>>>  AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader",
>>>>>
>>>> ()
>>>
>>>> ->
>>>>
>>>>> {
>>>>>
>>>>> ^
>>>>>
>>>>>both method invokeAsync(String,SerializableRunnableIF) in VM and
>>>>>
>>>> method
>>>
>>>> invokeAsync(String,SerializableCallableIF) in VM match
>>>>>
>>>>>where T is a type-variable:
>>>>>
>>>>>  T extends Object declared in method
>>>>> invokeAsync(String,SerializableCallableIF)
>>>>>
>>>>>
>>>>>
>>>>>
>>> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
>>>
>>>> warning: LdapCtxFactory is internal proprietary API and may be removed
>>>>>
>>>> in a
>>>>
>>>>> future release
>>>>>
>>>>>  env.put(Context.INITIAL_CONTEXT_FACTORY,
>>>>> com.sun.jndi.ldap.LdapCtxFactory.class.getName());
>>>>>
>>>>>^
>>>>>
>>>>> Note: Some input files use or override a deprecated API.
>>>>>
>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>>
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>>
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>>
>>>>> 1 error
>>>>>
>>>>>
>>>>> -Anil.
>>>>>
>>>>>
>

Re: Review Request 47686: GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).

[anilkumar gingade]

> On May 24, 2016, 9:44 p.m., Dan Smith wrote:
> > geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java,
> >  line 70
> > <https://reviews.apache.org/r/47686/diff/2/?file=1392007#file1392007line70>
> >
> > The javadocs for setAllowLeadingWildercard say this: "Note that this 
> > can produce very slow queries on big indexes."
> > 
> > Is this something we really want to enable?

This is a very useful option to fetch all the data from the lucene index...In 
database its common to use "select all"...It could be expensive based on the 
index data size, as this is similar to table scanI could not find any place 
saying this will impact other queries...If you don't see need of this, I am 
fine with  removing this...


- anilkumar


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


On May 24, 2016, 12:05 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47686/
> -------
> 
> (Updated May 24, 2016, 12:05 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to 
> eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).  
> 
> Added test to verify, the lucene index gets updated with expiration destroy 
> operation.   
> Also added support to specify wild-char as leading wild character with Lucene 
> Query.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  d22ca4a196df3b1a457b56c92da694bdbf792cc2 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java
>  1e2b63d0fc5c7fad79063199c473bbd9d4e6fd00 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
>  07780ca06a297851c8ff4cb498a09f726a0785d5 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationTest.java
>  15f5747231097df5223d97bb49110229efe6a824 
> 
> Diff: https://reviews.apache.org/r/47686/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Review Request 48188: GEODE-1495: Changes are made to remove the cached destroyed token/events from the CQ.

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Bruce Schuchardt, 
Jason Huynh, William Markito, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

The CQEvents as seen by CQs are cached in order to avoid applying CQ queries on 
old values.

In case of a destory CQEvent, the CQEvents are marked with destroy tokens and 
removed from
the cache after the CQEvent is added to HAQueue.
This works fine for the CQs registered locally, but for the CQs registered on 
peer server, the
CQs weren't removed from the cache, which resulted in generating wrong CQEvent 
for subsequent
operation.
This change removes the destroy CQevent from the cache after the CQEvent is 
distributed to
peer server.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
 6a7b4f2 

Diff: https://reviews.apache.org/r/48188/diff/


Testing
---

Reproduce the issue with manual testing. The test passed after the changes are 
made to remove cached destroy events from remote CQs.


Thanks,

anilkumar gingade

Re: build error with development branch...

[Anilkumar Gingade]

If gradle is using the java installed/set in my environment, then it is:

java version "1.8.0_20-ea"
Java(TM) SE Runtime Environment (build 1.8.0_20-ea-b05)
Java HotSpot(TM) 64-Bit Server VM (build 25.20-b05, mixed mode)

I could not see any build output that printed java version it used (nice to
have, if its not there)...

-Anil.



On Thu, Jun 2, 2016 at 2:14 PM, Dan Smith <dsm...@pivotal.io> wrote:

> Develop builds for me. And travis seems happy -
> https://travis-ci.org/apache/incubator-geode
>
> But this is actually pretty weird. In Intellij at least, it thinks that
> lambda maps to a SerializableCallable even though it doesn't return a
> value. I think maybe that's due to the while(true) part. If I comment that
> out, it maps to a runnable. It seems like this particular lambda actually
> *is* ambiguous since it will never return normally, it could be either a
> callable or a runnable.
>
> What JDK and what revision are you building with? Maybe some newer JDK is
> complaining about this?
>
> -Dan
>
> -Dan
>
> On Thu, Jun 2, 2016 at 1:58 PM, Anilkumar Gingade <aging...@pivotal.io>
> wrote:
>
> > Hi Devs,
> >
> > Anyone seeing this issue:
> >
> >
> >
> :geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
> > error: reference to invokeAsync is ambiguous
> >
> > AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", ()
> ->
> > {
> >
> >^
> >
> >   both method invokeAsync(String,SerializableRunnableIF) in VM and method
> > invokeAsync(String,SerializableCallableIF) in VM match
> >
> >   where T is a type-variable:
> >
> > T extends Object declared in method
> > invokeAsync(String,SerializableCallableIF)
> >
> >
> >
> /export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
> > warning: LdapCtxFactory is internal proprietary API and may be removed
> in a
> > future release
> >
> > env.put(Context.INITIAL_CONTEXT_FACTORY,
> > com.sun.jndi.ldap.LdapCtxFactory.class.getName());
> >
> >   ^
> >
> > Note: Some input files use or override a deprecated API.
> >
> > Note: Recompile with -Xlint:deprecation for details.
> >
> > Note: Some input files use unchecked or unsafe operations.
> >
> > Note: Recompile with -Xlint:unchecked for details.
> >
> > 1 error
> >
> >
> > -Anil.
> >
>

build error with development branch...

[Anilkumar Gingade]

Hi Devs,

Anyone seeing this issue:

:geode-core:compileTestJava/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/management/internal/security/MultiUserDUnitTest.java:62:
error: reference to invokeAsync is ambiguous

AsyncInvocation vm1Invoke = vm1.invokeAsync("run as data-reader", () ->
{

   ^

  both method invokeAsync(String,SerializableRunnableIF) in VM and method
invokeAsync(String,SerializableCallableIF) in VM match

  where T is a type-variable:

T extends Object declared in method
invokeAsync(String,SerializableCallableIF)

/export/india1/users/agingade/src/gemfire/open/geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java:89:
warning: LdapCtxFactory is internal proprietary API and may be removed in a
future release

env.put(Context.INITIAL_CONTEXT_FACTORY,
com.sun.jndi.ldap.LdapCtxFactory.class.getName());

  ^

Note: Some input files use or override a deprecated API.

Note: Recompile with -Xlint:deprecation for details.

Note: Some input files use unchecked or unsafe operations.

Note: Recompile with -Xlint:unchecked for details.

1 error


-Anil.

Re: Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Hi Team,

As proposed here, we added support to propagate eviction and expiration
(destroy) operation to AsyncEventQueue using single flag/attribute
"ignoreEvictionAndExpiration" by default which is true (to keep the same
behavior) and one could set (false) to receive eviction/expiration event...

But we come across a product issue, GEODE-1472, that cause data
inconsistency (with eviction destroy)For this reason we are planning to
break the "ignoreEvictionAndExpiration" attribute to eviction and
expiration specific:
"ignoreEvictionDestroy", "ignoreExpirationDestroy"...

Currently we are planning to support "ignoreExpirationDestroy",  and add
"ignoreEvictionDestroy" once GEODE-1472 is fixed...

Looking for comments on this...

Thanks,
-Anil.

https://issues.apache.org/jira/browse/GEODE-1472




On Tue, Apr 12, 2016 at 6:04 PM, Anilkumar Gingade <aging...@pivotal.io>
wrote:

> Kirk, We could not think of any such requirement...And with this
> application will get all the update operation and can take appropriate
> action (use or ignore)...
>
> -Anil.
>
>
>
> On Tue, Apr 12, 2016 at 5:46 PM, Kirk Lund <kl...@pivotal.io> wrote:
>
>> Would any user ever have a reason to enable forwarding of one type but not
>> the other? If so then I would separate them as forwardEvictionEvents() and
>> forwardExpirationEvents().
>>
>>
>> On Tue, Apr 12, 2016 at 5:44 PM, Kirk Lund <kl...@pivotal.io> wrote:
>>
>> > +1 for being more explicit with the "And" conjunction
>> >
>> > -Kirk
>> >
>> >
>> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker <aba...@pivotal.io>
>> wrote:
>> >
>> >> I’d prefer to insert a conjunction to clarify the meaning:
>> >>
>> >> forwardEvictionAndExpirationEvents()
>> >>
>> >>
>> >> $0.02,
>> >> Anthony
>> >>
>> >> On Apr 12, 2016, at 5:11 PM, Anilkumar Gingade <aging...@pivotal.io>
>> >> wrote:
>> >>
>> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any alternate
>> >> names?).
>> >>
>> >>
>> >>
>> >
>>
>
>

Re: Review Request 47803: field value could be null, need to handle this case

[anilkumar gingade]

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




geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/serializer/ReflectionLuceneSerializer.java
 (line 73)
<https://reviews.apache.org/r/47803/#comment199706>

This makes the null values to be not indexed

The NULL handling is common in data-storesQueries looking for null 
values are common...

It looks like there is a ISNULL option in Lucene, we need to invistage to 
see how we can store null and allow users to query null values...


https://forums.alfresco.com/forum/developer-discussions/other-apis/solved-empty-or-null-description-lucene-query-05052014-1521


- anilkumar gingade


On May 25, 2016, 12:20 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47803/
> ---
> 
> (Updated May 25, 2016, 12:20 a.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-1453
> https://issues.apache.org/jira/browse/GEODE-1453
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The field value could be null, when creating index, we need to handle it.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/serializer/PdxLuceneSerializer.java
>  3990614 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/serializer/ReflectionLuceneSerializer.java
>  a76478c 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationTest.java
>  4ebb9c4 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/serializer/PdxFieldMapperJUnitTest.java
>  278e818 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/serializer/ReflectionFieldMapperJUnitTest.java
>  c187022 
> 
> Diff: https://reviews.apache.org/r/47803/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Index management

[Anilkumar Gingade]

Agree

The indexes are operated using api/xml at a peer/server node level; there
is no client-server index operation command; one reason index destroy is
supported on member, to simulate what api is supported...As you mentioned
it may not make sense to have it from Gfsh.

-Anil.


On Mon, May 23, 2016 at 9:49 AM, Jens Deppe  wrote:

> ​Just recently I had reason to look​ at the gfsh *destroy index* call [1].
> I noticed that an index can be destroyed using *any one* of the following
> attributes: index name, region name, member name and group name.
>
> Deleting an index by name or removing all indexes from a region makes
> sense. However what does it mean to remove an index from a single member or
> from a group? Wouldn't that result in the possibility of having an
> 'unbalanced' set of indexes where some members hosting a region have an
> index defined, but other members don't? Seems like a recipe for serious
> misconfiguration. I really don't understand the semantics of these two
> scenarios. (I also couldn't find anything in the docs which explained this
> more). Even the QueryService interface has no methods to delete indexes by
> member or group.
>
> Unless there is an obvious scenario I don't understand, I'd like to propose
> we remove the ability (in gfsh at least) to destroy an index by *member* or
> *group*.
>
> --Jens
>
> [1]
>
> https://github.com/apache/incubator-geode/blob/8a3c351abd971ba740e77364a431aee7d5cc5b10/geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/IndexCommands.java#L327
>

Re: Review Request 47686: GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).

[anilkumar gingade]

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

(Updated May 24, 2016, 12:05 a.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
Smith, and xiaojian zhou.


Changes
---

Revoved the commented expiration action in the test.


Repository: geode


Description
---

GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to 
eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).
  
Added test to verify, the lucene index gets updated with expiration destroy 
operation.   
Also added support to specify wild-char as leading wild character with Lucene 
Query.


Diffs (updated)
-

  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 d22ca4a196df3b1a457b56c92da694bdbf792cc2 
  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java
 1e2b63d0fc5c7fad79063199c473bbd9d4e6fd00 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
 07780ca06a297851c8ff4cb498a09f726a0785d5 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationTest.java
 15f5747231097df5223d97bb49110229efe6a824 

Diff: https://reviews.apache.org/r/47686/diff/


Testing
---


Thanks,

anilkumar gingade

Review Request 47686: GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-11: Added changes to Lucene AEQ, to propagate destroy events due to 
eviction and expiration (by setting the flag ignoreEvictionAndExpiration()).
  
Added test to verify, the lucene index gets updated with expiration destroy 
operation.   
Also added support to specify wild-char as leading wild character with Lucene 
Query.


Diffs
-

  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 d22ca4a196df3b1a457b56c92da694bdbf792cc2 
  
geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/StringQueryProvider.java
 1e2b63d0fc5c7fad79063199c473bbd9d4e6fd00 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
 07780ca06a297851c8ff4cb498a09f726a0785d5 
  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationTest.java
 15f5747231097df5223d97bb49110229efe6a824 

Diff: https://reviews.apache.org/r/47686/diff/


Testing
---


Thanks,

anilkumar gingade

Write up on adding Gfsh commands.

[Anilkumar Gingade]

Hi Team,

I have created wiki on adding new gfsh command. If you have any additional
information or additional comments, please add it to the wiki page or let
me know.

https://cwiki.apache.org/confluence/display/GEODE/Adding+Gfsh+commands

Thanks,
-Anil.

Re: Review Request 47615: GEODE-988: Added wait for events to arrive on stopped CQ before it is stopped. The test stops the CQ and verifies no events are recieved in stopped state; it was doing that b

[anilkumar gingade]

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

(Updated May 19, 2016, 10:54 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.


Changes
---

Based on review removed waits for events that were not needed...


Repository: geode


Description
---

GEODE-988: Added wait for events to arrive on stopped CQ before it is stopped. 
The test stops the CQ and verifies no events are recieved in stopped state; it 
was doing that by checking operations/events that happend before stop and not 
counting the changes happened during stop. In a slower environment, it could so 
happen that the CQ may not have recieved all the events before it is stopped, 
thus causing the validation to fail.


Diffs (updated)
-

  
geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/CqPerfUsingPoolDUnitTest.java
 130f924643ad350539f02a59f34b6ba18cef1c10 

Diff: https://reviews.apache.org/r/47615/diff/


Testing
---

Reproduced the issue by slowing down the CQ listener processing. Verified the 
test passes with the changes...


Thanks,

anilkumar gingade

Re: Review Request 47606: GEODE-1412: ignore-eviction-expiration flag was not used in the http controller

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On May 19, 2016, 5:14 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47606/
> ---
> 
> (Updated May 19, 2016, 5:14 p.m.)
> 
> 
> Review request for geode, Anil Kumar B, Jinmei Liao, and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1412: ignore-eviction-expiration flag was not used in the http 
> controller
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/QueueCommandsController.java
>  83d7bc1da6f265d84ba154539217a735a10dbfe8 
> 
> Diff: https://reviews.apache.org/r/47606/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 47615: GEODE-988: Added wait for events to arrive on stopped CQ before it is stopped. The test stops the CQ and verifies no events are recieved in stopped state; it was doing that b

[anilkumar gingade]

> On May 19, 2016, 10 p.m., Jason Huynh wrote:
> > Long term this test could probably be broken up into smaller chunks as it's 
> > testing multiple scenarios

Agree...


> On May 19, 2016, 10 p.m., Jason Huynh wrote:
> > geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/CqPerfUsingPoolDUnitTest.java,
> >  line 432
> > <https://reviews.apache.org/r/47615/diff/1/?file=1388453#file1388453line432>
> >
> > I think having the waitForUpdate (which happens a few lines below) will 
> > be enough for cq_1?  He won't get the create and update out of order 
> > correct?

Yes...waiting for update is good enough...It doesn't recieve events out of 
order in this case/test. I added there, for debugging purpose, to identify 
which event got missed...If the test is working as expected, it should not add 
any overhead...


> On May 19, 2016, 10 p.m., Jason Huynh wrote:
> > geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/CqPerfUsingPoolDUnitTest.java,
> >  line 433
> > <https://reviews.apache.org/r/47615/diff/1/?file=1388453#file1388453line433>
> >
> > I don't think we need this one here (for cq_3), we have a wait for 
> > updated later and do not do any validation until after the update.

Its not needed...I will remove this validation...And send a new review 
request...


- anilkumar


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


On May 19, 2016, 9:47 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47615/
> -----------
> 
> (Updated May 19, 2016, 9:47 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
> Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-988: Added wait for events to arrive on stopped CQ before it is 
> stopped. The test stops the CQ and verifies no events are recieved in stopped 
> state; it was doing that by checking operations/events that happend before 
> stop and not counting the changes happened during stop. In a slower 
> environment, it could so happen that the CQ may not have recieved all the 
> events before it is stopped, thus causing the validation to fail.
> 
> 
> Diffs
> -
> 
>   
> geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/CqPerfUsingPoolDUnitTest.java
>  130f924643ad350539f02a59f34b6ba18cef1c10 
> 
> Diff: https://reviews.apache.org/r/47615/diff/
> 
> 
> Testing
> ---
> 
> Reproduced the issue by slowing down the CQ listener processing. Verified the 
> test passes with the changes...
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Review Request 47615: GEODE-988: Added wait for events to arrive on stopped CQ before it is stopped. The test stops the CQ and verifies no events are recieved in stopped state; it was doing that by ch

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-988: Added wait for events to arrive on stopped CQ before it is stopped. 
The test stops the CQ and verifies no events are recieved in stopped state; it 
was doing that by checking operations/events that happend before stop and not 
counting the changes happened during stop. In a slower environment, it could so 
happen that the CQ may not have recieved all the events before it is stopped, 
thus causing the validation to fail.


Diffs
-

  
geode-cq/src/test/java/com/gemstone/gemfire/cache/query/cq/dunit/CqPerfUsingPoolDUnitTest.java
 130f924643ad350539f02a59f34b6ba18cef1c10 

Diff: https://reviews.apache.org/r/47615/diff/


Testing
---

Reproduced the issue by slowing down the CQ listener processing. Verified the 
test passes with the changes...


Thanks,

anilkumar gingade

Re: [ANNOUNCE] Donation of GemFire native client code

[Anilkumar Gingade]

Thats a great newsIt opens up all our client code accessible to
community...

-Anil.


On Thu, May 19, 2016 at 8:56 AM, Anthony Baker  wrote:

> I am pleased to announce the donation of additional GemFire client drivers
> to the Geode community. This source code donation includes a C++ client and
> a .NET client.
>
> The C++ client allows an application to connect to a cluster using
> intelligent network routing for low latency reads and writes.  The C++
> client can additionally cache data locally and receive update notifications
> or register continuous queries.  The .NET client wraps the C++ libraries
> and enables .NET applications to be written for Geode.  Both of these
> clients are functionally equivalatent to the already donated Java client
> for Geode.
>
> The Software Grant Agreement for this code has been accepted by the ASF
> secretary.
>
> The donated code currently sits in a separate branch in the Geode
> repository named native-client-software-grant [1] and is awaiting community
> review.  I encourage everyone in the Geode community to review this
> donation and provide feedback.  In particular your input on build
> improvements would be really helpful.  Once the community has reached a
> consensus we can determine next steps and how this code might get merged
> into the develop branch [2] so that all users can access these features.
> Your suggestions are most welcome!
>
> Thanks,
> Anthony
>
> [1]
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tree;f=geode-client-native;h=0fd3464f85be2dba96ad1c2692b4bc28b1df1d64;hb=refs/heads/native-client-software-grant
> [2] https://issues.apache.org/jira/browse/GEODE-1416
>

Re: would anyone mind if I...

[Anilkumar Gingade]

+1

I am assuming there will be some marking between two cache instances...

Do they include xml and properties info too? if so it will be nice to have
some way to print those during debugging...

-Anil.



On Wed, May 18, 2016 at 3:12 PM, Bruce Schuchardt 
wrote:

> Would anyone mind if I modify the distributedTests to inhibit all of the
> banners that Geode logs when a cache/distributed-system is started?  They
> bloat the logs quite a bit and removing them would increase the chances
> that Jenkins failures would retain enough output to be useful.
>

Re: Review Request 47496: Adding transaction tests for lucene indexes

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImplIntegrationTest.java
 (line 81)
<https://reviews.apache.org/r/47496/#comment198231>

LuceneTestUtilities has region and index name; in case if it can be used.



geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImplIntegrationTest.java
 (line 112)
<https://reviews.apache.org/r/47496/#comment198232>

LuceneIntegrationTest has close cache...can we use/extend it?



geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImplIntegrationTest.java
 (line 306)
<https://reviews.apache.org/r/47496/#comment198233>

How about moving these puts into region initialization method?


- anilkumar gingade


On May 17, 2016, 10:54 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47496/
> ---
> 
> (Updated May 17, 2016, 10:54 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added integration tests to test three scenarios:
> 1.) the lucene indexes are not updated during an in flight transaction (begin 
> but before rollback or commit)
> 2.) the lucene indexes are updated after a commit
> 3.) the lucene indexes are not changed after a rollback
> 
> todo:
> Do we want to add a dunit test for multiple vms and threads doing 
> transactions?  I avoided adding this test for now as I thought that was more 
> of a "testing the geode transaction feature" rather than testing how the 
> feature affects lucene.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImplIntegrationTest.java
>  fa3392c 
> 
> Diff: https://reviews.apache.org/r/47496/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 46243: GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested with manual testing.

[anilkumar gingade]

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

(Updated May 16, 2016, 11 p.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.


Changes
---

Updated javadoc to reflect the type of events passed with 
setIgnoreEvictionAndExpiration attribute.


Repository: geode


Description
---

GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested 
with manual testing.

Sending the changes for early feedback on attribute/method names...

Need to add support for xml, gfsh...And new tests...


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueFactory.java
 fccb81e 

Diff: https://reviews.apache.org/r/46243/diff/


Testing
---

Did manual testing with AEQ with and without eviction and expiration.


Thanks,

anilkumar gingade

Re: Review Request 47004: a quick solution to wait for entry flushed into index

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
 (line 86)
<https://reviews.apache.org/r/47004/#comment197784>

Do we need to say about advanced version?



geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
 (line 88)
<https://reviews.apache.org/r/47004/#comment197776>

We need to define this in LunceneIndex interface to be used as public API.



geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
 (line 89)
<https://reviews.apache.org/r/47004/#comment197779>

I believe in our group session we passed two arguments. 1. Max wait time 1. 
Unit of sleep (iunstead of hard coded 200 mili sec)


- anilkumar gingade


On May 16, 2016, 5:39 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47004/
> ---
> 
> (Updated May 16, 2016, 5:39 a.m.)
> 
> 
> Review request for geode, anilkumar gingade and Dan Smith.
> 
> 
> Bugs: geode-1351
> https://issues.apache.org/jira/browse/geode-1351
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is for test purpose.
> 
> An advanced version will be implemented later using function execution.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneEventListener.java
>  9fdfd43 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
>  0b5f8fa 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesBase.java
>  c467a18 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImplJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/47004/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Review Request 47378: GEODE-11: Split out lucene tests of persistence and off heap

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On May 14, 2016, 12:25 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47378/
> ---
> 
> (Updated May 14, 2016, 12:25 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Persistence and offheap require some special before and after code to
> create and clean up the resources. Splitting these to separate
> integration tests.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexCreationIntegrationTest.java
>  6429143ea57d1cc71fa2fe30fe5af0ce826fc49c 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexCreationOffHeapIntegrationTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexCreationPersistenceIntegrationTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIntegrationTest.java
>  67775d229e93c0607fff53e6f64a583a04c0d382 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/test/LuceneTestUtilities.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/test/TestObject.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/test/package-info.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/47378/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Review Request 47372: GEODE-1209: Added gfsh support to set ignoreEvictionAndExpiration attribute for create AEQ command.

[anilkumar gingade]

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

Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
Jason Huynh, Jens Deppe, Kirk Lund, nabarun nag, Dan Smith, and xiaojian zhou.


Repository: geode


Description
---

GEODE-1209: Added gfsh support to set ignoreEvictionAndExpiration attribute for 
create AEQ command. Also cleaned up arguments for create AEQ function invoked 
by gfsh. Instead of object array the args are wrapped in args object.


Diffs
-

  
geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
 653bbdc 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommands.java
 89534a6 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/AsyncEventQueueFunctionArgs.java
 PRE-CREATION 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/CreateAsyncEventQueueFunction.java
 7481c0e 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java
 9bb573b 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/web/controllers/QueueCommandsController.java
 b8353fa 
  
geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/QueueCommandsDUnitTest.java
 691533d 

Diff: https://reviews.apache.org/r/47372/diff/


Testing
---


Thanks,

anilkumar gingade

Re: Review Request 47253: GEODE-430: Fixing races in UpdatePropegationDUnitTest

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On May 11, 2016, 8:11 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47253/
> ---
> 
> (Updated May 11, 2016, 8:11 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This test was failing with a couple of different race conditions
> 
> 1) It was not waiting for updates to make it to the second client,
> causing assertion failures. I added a wait.
> 
> 2) It was occasionally using a connection that was previously made to
> the server before it was killed, causing an unexpected socket closed. I
> refactored the test to not use internal APIs to do the put, but instead
> verify that the event was not sent to the client using a listener.
> 
> I also did some cleanup of the test - extended JUnit4CacheTestCase,
> removed the waits, used awaitility, removed an almost duplicate disabled
> test method and added the one extra assertion from that duplicate test
> to the enabled test method.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/UpdatePropagationDUnitTest.java
>  69781c4ff855974aeb9d32f8aafbcf40af046dc1 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/UpdatePropagationPRDUnitTest.java
>  8edac456c2595f83eef26d1ae9d25065bf69a44d 
> 
> Diff: https://reviews.apache.org/r/47253/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 47276: GEODE-1381: Tests of indexes on regions with overflow, eviction, expiration

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On May 12, 2016, 12:53 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47276/
> ---
> 
> (Updated May 12, 2016, 12:53 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding integration tests of indexes on these types of regions.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexCreationIntegrationTest.java
>  6f6f03a9d5e963176832513d1842f55513b78c6d 
> 
> Diff: https://reviews.apache.org/r/47276/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 47220: This is bug in test code

[anilkumar gingade]

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




geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java
 (line 39)
<https://reviews.apache.org/r/47220/#comment196962>

How about changing the name to SimpleTwoCacheServerDUnitTest? Within the 
words number 2 generally refers to "To"...But its upto you...



geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java
 (line 78)
<https://reviews.apache.org/r/47220/#comment196963>

Unsetting of the callback flag needs to be called even if there is any 
failure, right?
If thats the case, do we need to wrap this in a finally block?



geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java
 (line 83)
<https://reviews.apache.org/r/47220/#comment196964>

From the above it looks like we are not sure which one is the primary queue 
server...Are we expecting to close primary queue server or any server?


- anilkumar gingade


On May 11, 2016, 6:05 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47220/
> ---
> 
> (Updated May 11, 2016, 6:05 a.m.)
> 
> 
> Review request for geode and anilkumar gingade.
> 
> 
> Bugs: geode-1344
> https://issues.apache.org/jira/browse/geode-1344
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There're more than one thread that are try to connect and create proxy for 
> durable client. It's possible that the reinitialize() is called more than 
> once. But it should be at least once. 
> 
> I did not change the product code for durable client. It's my test code used 
> wrong expectation.
> 
> 
> Diffs
> -
> 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/Simple2CacheServerDUnitTest.java
>  4fdd88d 
> 
> Diff: https://reviews.apache.org/r/47220/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Review Request 46243: GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested with manual testing.

[anilkumar gingade]

> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java,
> >  line 1151
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370375#file1370375line1151>
> >
> > We're not generating event ids if there is an async event queue? What 
> > is this code for?
> > 
> > It seems like this check ought to be extracted into it's own method.

The destroy event for expiration on PR wasn't setting eventId which was causing 
NPE in the code:
at 
com.gemstone.gemfire.cache.asyncqueue.internal.SerialAsyncEventQueueImpl.setModifiedEventId(SerialAsyncEventQueueImpl.java:243)

Earlier this was not an issue, as we were not sending destroy events to AEQs.

The eventId is getting set based on the call to generateEventID()...the change 
was made to retrun true when there is an AEQ on the bucket region.

As we spoke I will remove the check for bucketRegion and allow it to generated 
event id in all cases except for admin region.


> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java,
> >  line 6645
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370375#file1370375line6645>
> >
> > Are you sure there aren't another internal regions that ought to notify 
> > the gateway? Why did you add this check?
> > 
> > THis might read cleaner if you had a separate if for each check with a 
> > comment explaining why it's skipped.

This was to filter out events from internal region, in the begining itself...So 
that its clean and easy to debug in the later part of the code. I observed 
there were lot of events coming from monitoring region. I will remove the check 
for internal region.


> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java,
> >  line 6650
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370375#file1370375line6650>
> >
> > Remove this log message.

Sorry, missed removing log messages before sending it for review.


> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java,
> >  line 857
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370376#file1370376line857>
> >
> > Remove this log message.

Sorry, missed removing log messages before sending it for review.


> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java,
> >  line 865
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370376#file1370376line865>
> >
> > I wonder if there are use cases where we would want to pass these 
> > events to the WAN? Is there a reason we need is AEQ check here?

By talking to barry, it seems its a design choice not send the local operation 
over the wan (or propogate it to the remote cluster)...And thinking about it, 
its valid option as the cluster setups/configuration/requirements could be 
different.


> On May 5, 2016, 9:13 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java,
> >  line 63
> > <https://reviews.apache.org/r/46243/diff/2/?file=1370383#file1370383line63>
> >
> > This is not a unit test if it's creating a cache. Should be marked as 
> > an integration test.

You are right, i will change this as integration test.


- anilkumar


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


On May 6, 2016, 12:45 a.m., anilkumar gingade wrote:
> 
> -------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46243/
> ---
> 
> (Updated May 6, 2016, 12:45 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
> Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested 
> with manual testing.
> 
> Sending the changes for early feedback on attribute/method names...
> 
> Need to add support for xml, gfsh...And new tests...
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueue.java
>

Re: Review Request 46243: GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested with manual testing.

[anilkumar gingade]

> On April 19, 2016, 12:18 a.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java,
> >  line 6727
> > <https://reviews.apache.org/r/46243/diff/1/?file=1346039#file1346039line6727>
> >
> > What is this check for for isInternalRegion for?

This was to filter out events from internal region, in the begining itself...So 
that its clean and easy to debug in the later part of the code. I observed 
there were lot of events coming from monitoring region. I will remove the check 
for internal region.


> On April 19, 2016, 12:18 a.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java,
> >  line 870
> > <https://reviews.apache.org/r/46243/diff/1/?file=1346040#file1346040line870>
> >
> > Is looks like in the old code this isLocal check was commented out?

isLocal check was done in LocalRegion.notifyGateWaySender()...To keep the logic 
simple, in one place i moved this check as part of checkForDistribution().


- anilkumar


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


On May 6, 2016, 12:45 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46243/
> -------
> 
> (Updated May 6, 2016, 12:45 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Darrel Schneider, 
> Jason Huynh, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested 
> with manual testing.
> 
> Sending the changes for early feedback on attribute/method names...
> 
> Need to add support for xml, gfsh...And new tests...
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueue.java
>  a2b8b0f62333082e8eaf87354c0a2700f7428608 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueFactory.java
>  3e30b3847c2cd1c4fc72f342f0898a1e56cbce2e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  312e880251cb5fdcfb79b81d888ec5a85649d9da 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueImpl.java
>  6b3eb4a827add8c8551bcd095eba0ab69a74dbd4 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/wan/GatewaySender.java 
> c5b5d3aca14000e82b25e0eb156f789f7e1fc753 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
> 3ad294c10463b87ed9685b4c7f767523d0a52335 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java
>  fe09d031c7e326b4eb0cc3f63700c282b734b842 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderAttributes.java
>  1cef940f8ebacb22cd3b08513ea3083ecd1df909 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/AsyncEventQueueCreation.java
>  001566504db6eb2828cdcc3eba824e90d1df70e3 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXml.java
>  aa7d49a654fcc0c7d2419546f4b4b5e1c271 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlGenerator.java
>  ea3c975267b3b05cd1e9350ca464aba70e459113 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlParser.java
>  f344938350a1043655f27f75eb7a9cbf9246ac30 
>   
> geode-core/src/main/resources/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd
>  cc6d189e7fb4ed05f7bf35a9e43bafc8dc53056f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache30/CacheXmlGeode10DUnitTest.java
>  57e3a13b320e302f4be4ff40aa976eabd929435a 
> 
> Diff: https://reviews.apache.org/r/46243/diff/
> 
> 
> Testing
> ---
> 
> Did manual testing with AEQ with and without eviction and expiration.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Re: Review Request 46916: GEODE-641: Adding default methods to the Function interface

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On May 2, 2016, 10:55 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46916/
> ---
> 
> (Updated May 2, 2016, 10:55 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Adding default methods to Function so that Function is now a functional
> interface and lambda expressions can be used for functions.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/execute/Function.java 
> 2e4e0660f1242797906de268e4a11e736215c7c6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/execute/FunctionAdapter.java
>  c4cfeed909c843ab1eb4775258685b2691cf5fb9 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/execute/FunctionAdapterJUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46916/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 46243: GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested with manual testing.

[anilkumar gingade]

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

(Updated May 4, 2016, 1:09 a.m.)


Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
nabarun nag, Dan Smith, and xiaojian zhou.


Changes
---

Added changes based on the revivew comments (changing name from 
forwardEvictionAndExpiration to isIgnoreEvictionAndExpiration).
Added Unit test to cover the possible cases with eviction/expiration with 
replicated and PR.
Added XML support for isIgnoreEvictionAndExpiration attribute and tests for XML 
creation.


Repository: geode


Description
---

GEODE-1209: Added new attribute to forward eviction/expiration to AEQ. Tested 
with manual testing.

Sending the changes for early feedback on attribute/method names...

Need to add support for xml, gfsh...And new tests...


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueue.java
 a2b8b0f62333082e8eaf87354c0a2700f7428608 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueFactory.java
 3e30b3847c2cd1c4fc72f342f0898a1e56cbce2e 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
 312e880251cb5fdcfb79b81d888ec5a85649d9da 
  
geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueImpl.java
 6b3eb4a827add8c8551bcd095eba0ab69a74dbd4 
  geode-core/src/main/java/com/gemstone/gemfire/cache/wan/GatewaySender.java 
c5b5d3aca14000e82b25e0eb156f789f7e1fc753 
  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
3ad294c10463b87ed9685b4c7f767523d0a52335 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java
 fe09d031c7e326b4eb0cc3f63700c282b734b842 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderAttributes.java
 1cef940f8ebacb22cd3b08513ea3083ecd1df909 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/AsyncEventQueueCreation.java
 001566504db6eb2828cdcc3eba824e90d1df70e3 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXml.java
 aa7d49a654fcc0c7d2419546f4b4b5e1c271 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlGenerator.java
 ea3c975267b3b05cd1e9350ca464aba70e459113 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/xmlcache/CacheXmlParser.java
 f344938350a1043655f27f75eb7a9cbf9246ac30 
  
geode-core/src/main/resources/META-INF/schemas/geode.apache.org/schema/cache/cache-1.0.xsd
 cc6d189e7fb4ed05f7bf35a9e43bafc8dc53056f 
  
geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/com/gemstone/gemfire/cache30/CacheXmlGeode10DUnitTest.java
 57e3a13b320e302f4be4ff40aa976eabd929435a 

Diff: https://reviews.apache.org/r/46243/diff/


Testing
---

Did manual testing with AEQ with and without eviction and expiration.


Thanks,

anilkumar gingade

User Defined Aggregate (UDA) function support in Geode OQL

[Anilkumar Gingade]

Hi Geode Devs,

To enhance Geode query functionalities; we had started initiative to
support Aggregate and UDA functionalities using a common frame work.

The spec for this can be found at:
https://cwiki.apache.org/confluence/display/GEODE/OQL+Aggregate+functions+and+UDA

As part of first phase implementation, we added common frame-work and
support for standard aggregate functions like Min, Max, Avg and Sum, which
is available in the Geode develop branch.

As a second phase implementation, we have added support for UDAs which is
available as feature branch.

feature/GEODE-1269

We are looking for input, comments and contribution to that UDA
functionality, try it and let us know your feedback.

Thanks,
-Anil.

Its been a year....

[Anilkumar Gingade]

Hi Geode,

Thought of sharing this milestone...

Wow...Its been a year...In last year ApacheCON (Apr 2015) we announced open
sourcing Geode, we made the Geode source available to the Apache
community...Its been a great journey from that point...

The geode community is growing and contributing to the Geode code
base...Thanks to all the developers and community, we have successfully
achieved two milestone releases and heading towards Graduations...

Great work team and contributors...

Thanks,
-Anil.

Re: Review Request 46625: when there're multiple cache servers on the same jvm, keep the first proxy for the each client

[anilkumar gingade]

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




geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java
 (line 510)
<https://reviews.apache.org/r/46625/#comment194214>

Here, based on the stale-proxy we are trying to see whether to create new 
proxy or not...

The isConnect() flag seems to be added for durable clients than 
non-durable...

What if there is a stale proxy and its status is still connected?

We also need to think about durable clients trying to connect to two 
servers in the same jvm (similar scenrio).

The other solution could be:
- While client is trying to make connection, if there is way to know the 
two servers are on the same jvm and ignore. OR If the endpoints are coming from 
locator, see locator can only return the server locations/connections that are 
not on the same jvm.
- OR on the server side if the client is already connected with different 
port on this server (and there are multiple servers running on this JVM)


- anilkumar gingade


On April 25, 2016, 6:01 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46625/
> ---
> 
> (Updated April 25, 2016, 6:01 a.m.)
> 
> 
> Review request for geode and anilkumar gingade.
> 
> 
> Bugs: GEODE-1183
> https://issues.apache.org/jira/browse/GEODE-1183
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Current API allows us to create 2 cache servers on the same JVM, then the 
> client
> will try to create 2 queues to that JVM, one secondary and one primary.
> But the proxy is actually the same (since there's only one client), so the
> CCN keeps destroying and recreating the proxy.
> 
> To fix, we will keep the first proxy and reject the duplicate creating.
> Then the secondary proxy will automatically become primary.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java
>  1ba2294 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/CacheClientNotifierDUnitTest.java
>  8bf819c 
> 
> Diff: https://reviews.apache.org/r/46625/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: M2 release update

[Anilkumar Gingade]

Great...

Thanks Dan; for being the release manager and successfully getting the
release out...good work...

-Anil.


On Fri, Apr 22, 2016 at 11:24 AM, Dan Smith  wrote:

> Quick update on the M2 release. It passed the vote on the incubator general
> list, we're just working on updating the website and making sure the
> release was published everywhere before sending an announcement.
>
> -Dan
>

Re: Review Request 46354: GEODE-1072: Removing HDFS related code

[anilkumar gingade]

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


Fix it, then Ship it!




Ship It!


geode-core/src/main/java/com/gemstone/gemfire/cache/AttributesFactory.java 
<https://reviews.apache.org/r/46354/#comment193005>

Seems like a good feature to have on the regions, is this tied to HDFS? if 
not can we retain this?



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionMap.java
 (line 1147)
<https://reviews.apache.org/r/46354/#comment193125>

Is this HDFS/custome eviction specific?


- anilkumar gingade


On April 19, 2016, 12:35 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46354/
> ---
> 
> (Updated April 19, 2016, 12:35 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removing all HDFS and EvictionCriteria created code. This code will be
> reinstated on a branch to be cleaned up and merged as a separate module.
> 
> 
> Diffs
> -
> 
>   geode-core/build.gradle 2206018efeebb9c0105834dd09760592b7032873 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/AttributesFactory.java 
> 201c1aabb2f5452b980a3aa5ae7e1c5a949c1e61 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/AttributesMutator.java 
> eb46433979ea6c3c111d62ed16ed8eaba7bae143 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/CustomEvictionAttributes.java
>  c2bc41b93e458d3defa79c1ec5246368ede008ef 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/DataPolicy.java 
> 1e87c0f164e77555e6685841f75dd41044a3ab90 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/EvictionCriteria.java 
> 8df201c047e6ee1e19cd0ffda558eb658589d868 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/Operation.java 
> 7a63855389927a3805a2ecc86cce06a11a9a64fb 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/RegionAttributes.java 
> dd5c0e0cb1ae553b4bbc9e044520235994adccb6 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/RegionFactory.java 
> 729374ed6b6050dde92fd00de88615ede3283fd4 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/asyncqueue/internal/AsyncEventQueueFactoryImpl.java
>  d15222b85828d8b450e3aa5c8858502259a9e4e6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSIOException.java 
> d9b6179fa0377b18d6d333a022acc06ef52a8032 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStore.java 
> 45ba370034c6b1385a35763bdff575f31c6694e8 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStoreFactory.java
>  0d80a67354f61546f2ec13c6a3c4c43fc51a7288 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/HDFSStoreMutator.java
>  d98c9cdb187f38d023cd6d5c4212fef1cb514bc8 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/StoreExistsException.java
>  de21b2322cc41adf997607f0dd682006c055fe73 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/FailureTracker.java
>  789d49765f4e4959a6e5b88b8ace3f8d5b99fb2b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/FlushObserver.java
>  f69b3dc3b77854b10dfde40f503264a437a3163f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSBucketRegionQueue.java
>  9127e4dbc3edbe0dbd993ca3b72b68ed8cbb65ff 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSEntriesSet.java
>  c8b7b282487b48edfcbed8f21a69c8b2b3c33de3 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSEventListener.java
>  607650f30d44d4a792e0bbca3c2d495c84d098d1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSEventQueueFilter.java
>  0860e752dec9e0aa7d8efc21d09e0b84ea7b1a04 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSGatewayEventImpl.java
>  db99e7eb9b10bdfda4f64332221b73bf085e5ccd 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSIntegrationUtil.java
>  740a607d48dd51d3cf82709f441fe7bbd96d37aa 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSParallelGatewaySenderQueue.java
>  1e6a0343ca9782f040d26c2259fe330155dfde5b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/internal/HDFSStoreConfigHolder.java
>  16d3d87762323b5dde0c90e2e6e91c356e86fe43 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/hdfs/inter

Re: Review Request 46356: GEODE-978: Increasing the port range used in CacheXmlGateway tests

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 19, 2016, 12:50 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46356/
> ---
> 
> (Updated April 19, 2016, 12:50 a.m.)
> 
> 
> Review request for geode and Kirk Lund.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The tests were previously hardcoding a very narrow range of ports.
> 
> 
> Diffs
> -
> 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/cache/CacheXml70GatewayDUnitTest.java
>  e9a47e26d8f7fbb217960114c9095282e988ccfa 
>   
> geode-wan/src/test/java/com/gemstone/gemfire/cache/CacheXml80GatewayDUnitTest.java
>  d04e91615100a1d405cc14438f8ee2413fba7143 
> 
> Diff: https://reviews.apache.org/r/46356/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 46239: UnitTest for LuceneIndexForPartitionedRegion

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 15, 2016, 12:16 a.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46239/
> ---
> 
> (Updated April 15, 2016, 12:16 a.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Not sure if this is needed at this point, but with this new unit test it gets 
> slightly more coverage in a fraction of the time (takes 2 seconds on my 
> laptop for 18 tests) it takes to run LuceneServiceImplJUnitTest (9 seconds 
> for 5 tests).  None of the cache calls are on a real cache so that gives some 
> speed savings, although as you can see, the difference is only in seconds at 
> this point.
> 
> Allows ability to test that double initialize calls do not invoke multiple 
> file region creates (which may have been hard to test before or is this case 
> even possible?)
> 
> refactored LuceneIndexForPartitionRegion so that a unit test for it could 
> test specific units, but also allowing tests for initialize() to be stubbed 
> out.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  25b63a4 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/46239/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 46240: GEODE-336: Make Function extends Identifiable

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 15, 2016, 12:23 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46240/
> ---
> 
> (Updated April 15, 2016, 12:23 a.m.)
> 
> 
> Review request for geode and anilkumar gingade.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Function was extending Identifiable without specifying the generic
> type.
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/com/gemstone/gemfire/cache/execute/Function.java 
> 2e4e0660f1242797906de268e4a11e736215c7c6 
> 
> Diff: https://reviews.apache.org/r/46240/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: [VOTE] RC2: Apache Geode (Incubating) second Milestone release - v1.0.0-incubating.M2

[Anilkumar Gingade]

+1. Great work Dan...

Downloaded  "apache-geode-src-1.0.0-incubating.M2.tar.gz"
Did a clean and build on my mac:

BUILD SUCCESSFUL
Total time: 5 mins 38.668 secs

Thanks,
-Anil.


On Wed, Apr 13, 2016 at 3:55 PM, Dan Smith  wrote:

> This is second release candidate for Apache Geode, version
> 1.0.0-incubating.M1.
>
> *** Please download, test and vote by Monday, Apr 18, 0800 PST
>
> If you are wondering why you didn't see RC1, it's because I caught a
> mistake after I created the tag but before sending out the vote. Thanks for
> all the hard work going into this milestone!
>
> It fixes the following issues:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318420=12334709
>
> Note that we are voting upon the source (tag):
> rel/v1.0.0-incubating.M2.RC2
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tag;h=refs/tags/rel/v1.0.0-incubating.M2.RC2
>
> Commit ID: 3ac74a4e2c72677ef7c85df77922c645c7cce598
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=commit;h=3ac74a4e2c72677ef7c85df77922c645c7cce598
>
> Source and binary files:
>
>
> https://dist.apache.org/repos/dist/dev/incubator/geode/1.0.0-incubating.M2.RC2/
> <
> https://repository.apache.org/content/repositories/snapshots/org/apache/geode
> >
>
> Maven staging repo:
>
> https://repository.apache.org/content/repositories/orgapachegeode-1004/
> 
>
> Geode's KEYS file containing PGP keys we use to sign the release:
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=blob_plain;f=KEYS;hb=refs/heads/release/1.0.0-incubating.M2
> Release Key: pub   4096R/A1688D97 2016-01-20
> Fingerprint: 1776 0439 68F0 FD83 62C7  2CCF 444C 1D20 A168 8D97
>
> Thanks,
> Dan Smith
>

Re: Review Request 45711: GEODE-1044: Not initializing query array for every test, code clean up

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 4, 2016, 10:53 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45711/
> ---
> 
> (Updated April 4, 2016, 10:53 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The query array is not needed for most tests that use QueryTestUtils.  
> Instead of tests that need it will need to invoke the method to initialize 
> the array explicitly.
> 
> Removed code that was not being called by any other class
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/QueryTestUtils.java 
> d53a85b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/QueryTestUtilsJUnitTest.java
>  15cae6a 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/CompactRangeIndexDUnitTest.java
>  86f629d 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/HashIndexDUnitTest.java
>  4db6fc0 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/index/CompactRangeIndexJUnitTest.java
>  a24f7bf 
> 
> Diff: https://reviews.apache.org/r/45711/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 46154: GEODE-1018: Retrieve queues only once gateway listener to avoid a race

[anilkumar gingade]

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


Ship it!




Ship It!

- anilkumar gingade


On April 13, 2016, 5:18 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46154/
> ---
> 
> (Updated April 13, 2016, 5:18 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The second call to getQueues could have returned null due to a
> concurrent change. By fetching the queues only once we avoid a race.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialSecondaryGatewayListener.java
>  5cb0ec0f4b993e76e96b68d1e5722e9b34dbba1b 
> 
> Diff: https://reviews.apache.org/r/46154/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Kirk, We could not think of any such requirement...And with this
application will get all the update operation and can take appropriate
action (use or ignore)...

-Anil.



On Tue, Apr 12, 2016 at 5:46 PM, Kirk Lund <kl...@pivotal.io> wrote:

> Would any user ever have a reason to enable forwarding of one type but not
> the other? If so then I would separate them as forwardEvictionEvents() and
> forwardExpirationEvents().
>
>
> On Tue, Apr 12, 2016 at 5:44 PM, Kirk Lund <kl...@pivotal.io> wrote:
>
> > +1 for being more explicit with the "And" conjunction
> >
> > -Kirk
> >
> >
> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker <aba...@pivotal.io>
> wrote:
> >
> >> I’d prefer to insert a conjunction to clarify the meaning:
> >>
> >> forwardEvictionAndExpirationEvents()
> >>
> >>
> >> $0.02,
> >> Anthony
> >>
> >> On Apr 12, 2016, at 5:11 PM, Anilkumar Gingade <aging...@pivotal.io>
> >> wrote:
> >>
> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any alternate
> >> names?).
> >>
> >>
> >>
> >
>

Proposal to allow eviction and expiration operations/events with AsyncEventQueue.

[Anilkumar Gingade]

Hi Team,

The AEQ implementation in Geode currently does not support distribution of
eviction or expiration operations...This makes the external source
maintained using AEQ to be out of sync with data that has been
removed/invalidated through eviction and expiration.

Jira ticket: https://issues.apache.org/jira/browse/GEODE-1209

AEQ Documentation:
http://gemfire.docs.pivotal.io/docs-gemfire/latest/developing/events/implementing_write_behind_event_handler.html#implementing_write_behind_cache_event_handling

We are proposing to add new AEQ factory method (attribute) to allow
eviction and expiration operation to be propagated to AEQ listeners.

AsyncEventQueueFactory factory = cache.createAsyncEventQueueFactory().
*forwardEvictionExpirationEvents()*;

*New attribute:* "forwardEvictionExpirationEvents()" (Any alternate names?).

By default this will set to false. This also makes sure that backward
compatibility with existing AEQ implementation is not broken.

Please let me know if you have any comments/feedback.

-Anil.