from:"\"Anilkumar Gingade\""



> On Aug. 12, 2016, 4:28 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 49
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line49>
> >
> > This could probably extend ExternalResource rather than directly 
> > implementing TestRule.

Changed to extend ExternalResource.


> On Aug. 12, 2016, 4:28 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 99
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line99>
> >
> > I'm not sure getLocatorVM is the right thing to call this. It's not 
> > really getting the locator, it's actually configuring the locator. I 
> > suspect many tests you might not actually need to get the locator VM.
> > 
> > Could the Rule just set this stuff up before the test runs, I wonder?

The idea here is to create cluster (locator, and nodes) using the given/custom 
properties...This simplifies setting up a cluster for those tests...We could 
change the Rule name appropriately, i could not come up with a better name

There could be requirement for a test where it needs a vm configured with 
specified properties...We could add one more Rule that can do that...


> On Aug. 12, 2016, 4:28 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 113
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line113>
> >
> > What if someone calls getVM instead of getNodeVM? I wonder if it would 
> > be possible to make this work so that someone doesn't need to call 
> > getNodeVM?

One could call getVm and configure it as they want (create a new DS)...And join 
the cluster using the locator port from the Locator configured in Rule.


> On Aug. 12, 2016, 4:28 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 122
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line122>
> >
> > Use port 0 instead to avoid potential races. You can get the port back 
> > from the locator after it starts. See DUnitLauncher.startLocator.

Done.


> On Aug. 12, 2016, 4:28 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/test/dunit/rules/LocatorServerConfigurationRule.java,
> >  line 129
> > <https://reviews.apache.org/r/51010/diff/1/?file=1471613#file1471613line129>
> >
> > This could be a lambda: locator.invoke(() -> {...})

Done.


- anilkumar


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


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.


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

(Updated Aug. 12, 2016, 11:58 p.m.)


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


Changes
---

Made changes based on review comments. Extening ExternalResource. Using Lambda 
expression. Use of 0 for locator port. Seperating test for group and non-group 
members.


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

  
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.



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



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

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


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

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

  
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.

2016-08-11 Thread 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

2016-08-10 Thread 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

2016-08-10 Thread 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

2016-08-08 Thread 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&version=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/
> > > > > > >>> 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,
> > > > > > >>>
> > > > > > >>> --
> >

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

2016-08-08 Thread 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

2016-07-27 Thread 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.

2016-07-26 Thread 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.

2016-07-22 Thread 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

2016-07-19 Thread 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

2016-07-15 Thread 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

2016-07-15 Thread 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

2016-07-15 Thread 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

2016-07-13 Thread 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&version=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

2016-07-11 Thread 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

2016-07-07 Thread 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?

2016-06-30 Thread 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: [GitHub] incubator-geode issue #178: GEODE-11: Pagination of Lucene query results aft...

2016-06-30 Thread Anilkumar Gingade

Thats rightIts hard to predict if there could be any entries, by the
time hasNext() and next() is called...We need to capture this in the the
docs...

-Anil.


On Wed, Jun 29, 2016 at 5:27 PM, upthewaterspout  wrote:

> Github user upthewaterspout commented on the issue:
>
> https://github.com/apache/incubator-geode/pull/178
>
> +1 looks good. One minor thing - I think could might result in
> hasNext() returning true followed by next() returning page with no elements
> if the last element gets deleted, is that right?
>
>
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
>

Re: Podling Report Reminder - July 2016

2016-06-30 Thread Anilkumar Gingade

Looks good...

-Anil.

On Thu, Jun 30, 2016 at 7:55 AM, Swapnil Bawaskar 
wrote:

> +1
>
> On Thu, Jun 30, 2016 at 7:43 AM, Michael Stolz  wrote:
>
> > +1 Looks good
> >
> > --
> > Mike Stolz
> > Principal Engineer - Gemfire Product Manager
> > Mobile: 631-835-4771
> > On Jun 28, 2016 7:48 PM, "Nabarun Nag"  wrote:
> >
> > > Hi
> > >
> > > Please find below the draft of the podling report.
> > >
> > > Any feedback is welcome.
> > >
> > > Regards
> > > Naba
> > >
> > > 
> > >
> > > Geode
> > >
> > > Geode is a data management platform that provides real-time, consistent
> > > access to data-intensive applications throughout widely distributed
> cloud
> > > architectures.
> > >
> > > Geode has been incubating since 2015-04-27.
> > >
> > > Three most important issues to address in the move towards graduation:
> > >
> > > - Rename packages to org.apache
> > > - Expanding the community to include contributors and committers
> outside
> > of
> > > Pivotal.
> > > - Establish a release cadence.
> > >
> > > Any issues that the Incubator PMC (IPMC) or ASF Board wish/need to be
> > > aware of?
> > >
> > > None
> > >
> > > How has the community developed since the last report?
> > >
> > > - We continue to work on the “Three most important issues to move
> towards
> > > graduation” from our previous report.
> > > - We had our second public release (1.0.0-incubating.M2).
> > > - We added 1 new committer.
> > > - We are about to have our third release (1.0.0-incubating.M3).
> > > - The Geode Clubhouse hosted a meeting covering the following topics :
> > > - “Cluster Replication via WAN” by Mike Stolz
> > > - “Southwest Airlines' Experience with Geode & GemFire at Scale” by
> Brian
> > > Dunlap
> > >
> > > - The breakdown of JIRA tickets is the following :
> > > - Q3/2015 306 created, 138 resolved
> > > - Q4/2015 342 created, 225 resolved
> > > - Q1/2016 438 created, 359 resolved
> > > - Q2/2016 451 created, 322 resolved [As of June 28th, 2016]
> > >
> > > - There was a total of 169 pull requests on Github with 6 still open.
> > >
> > > - The breakdown of the mailing lists messages for April, May, June of
> > > 2016:
> > > - org.apache.geode.issues 3,992
> > > - org.apache.geode.commits 3,572
> > > - org.apache.geode.dev2,006
> > > - org.apache.geode.user  273
> > >
> > > - There are now 155 subscribers on the dev and 165 on the user mailing
> > list
> > >
> > > How has the project developed since the last report?
> > >
> > > - Had our second release, 1.0.0-incubating.M2, on April 22, 2016.
> > > - Donation of native client components which included a C++ client and
> a
> > > .NET client.
> > > - Inclusion of WAN and CQ components in the second release.
> > > - Rotated release manager responsibilities for second and soon to be
> > third
> > > release.
> > > - Discussions about donation of documentation.
> > > - Geode portfile was added to MacPorts.
> > > - joptsimple source replaced with binary dependency.
> > > - Active discussions on topics like integrated security for Geode and
> > > wording of the website.
> > >
> > > Community events:
> > > - June 2016
> > >  - Midwest In Memory Data Grid Meet Up on using Apache Geode for
> real
> > > time transaction.
> > >(
> > >
> >
> http://www.meetup.com/Chicago-In-Memory-Data-Grid-Meetup/events/230810905/
> > > )
> > >
> > >  - Apache Geode meetup in Tokyo
> > >(http://pivotal-japan.connpass.com/event/33297/)
> > >
> > > Date of last release:
> > >
> > >   2016-04-22
> > >
> > > When were the last committers or PMC members elected?
> > >
> > >  Nabarun Nag (2016-06-14)
> > >
> > > Signed-off-by:
> > >
> > >   [ ](geode) Konstantin Boudnik
> > >   [ ](geode) Chip Childers
> > >   [ ](geode) Justin Erenkrantz
> > >   [ ](geode) Jan Iversen
> > >   [ ](geode) Chris Mattmann
> > >   [ ](geode) William A. Rowe Jr.
> > >   [ ](geode) Roman Shaposhnik
> > >
> > >
> > > On Tue, Jun 28, 2016 at 10:41 AM Nabarun Nag  wrote:
> > >
> > > > Jason and I are giving it a shot. I will send the first draft soon.
> > > >
> > > > Regards
> > > > Naba
> > > >
> > > > On Tue, Jun 28, 2016 at 9:58 AM Dan Smith  wrote:
> > > >
> > > >> I can take a crack at this if no one else wants to do it. I'll need
> > some
> > > >> help from people have done the previous reports.
> > > >>
> > > >> -Dan
> > > >>
> > > >> On Sun, Jun 26, 2016 at 2:02 PM,  wrote:
> > > >>
> > > >> > Dear podling,
> > > >> >
> > > >> > This email was sent by an automated system on behalf of the Apache
> > > >> > Incubator PMC. It is an initial reminder to give you plenty of
> time
> > to
> > > >> > prepare your quarterly board report.
> > > >> >
> > > >> > The board meeting is scheduled for Wed, 20 July 2016, 10:30 am
> PDT.
> > > >> > The report for your podling will form a part of the Incubator PMC
> > > >> > report. The Incubator PMC requires your report to be submitted 2
> > weeks
> > > >> > before the board meeting, to allow sufficient time for review and
> > > >> > submiss

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

2016-06-29 Thread 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

2016-06-23 Thread 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

2016-06-20 Thread 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

2016-06-20 Thread 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()).

2016-06-17 Thread 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

2016-06-17 Thread 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()).

2016-06-17 Thread 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 48738: GEODE-1209 Changes to ignoreEvictionAndExpiration AEQ attribute based on the new proposal (changing ignoreEvictionAndExpiration to forwardExpirationDestroy)

2016-06-16 Thread anilkumar gingade



> On June 15, 2016, 9:34 p.m., Dan Smith wrote:
> > geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/AbstractGatewaySender.java,
> >  line 815
> > <https://reviews.apache.org/r/48738/diff/1/?file=1420204#file1420204line815>
> >
> > You could probably get rid of the nested if conditions here:
> > 
> >   // Check if its AEQ and is configured to forward expiration 
> > destroy events.
> > if (event.getOperation().isExpiration() && this.isAsyncEventQueue() 
> > && this.isForwardExpirationDestroy()) {
> > return true;
> > } 
> > 
> > 
> > if (event.getOperation().isLocal() || 
> > event.getOperation().isExpiration()) {
> >   return false;
> > }

The reason I added is to have eviction/expiration in the same context...I can 
break it down...


> On June 15, 2016, 9:34 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java,
> >  line 283
> > <https://reviews.apache.org/r/48738/diff/1/?file=1420216#file1420216line283>
> >
> > If you use an assertion in the below awaility clause, you woudln't need 
> > a System.out.println.

This is for debugging...Forgot to remove...


> On June 15, 2016, 9:34 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java,
> >  line 240
> > <https://reviews.apache.org/r/48738/diff/1/?file=1420216#file1420216line240>
> >
> > This is one big test method with a lot of boolean flags to check 
> > different conditions. Maybe this should be broken into smaller, simpler 
> > test methods? For example checkForInvalidOp could be it's own method, 
> > rather than a flag.

I am breaking it down...All the validations are not required in all methods...I 
am moving validations within test methods.


> On June 15, 2016, 9:34 p.m., Dan Smith wrote:
> > geode-core/src/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java,
> >  line 262
> > <https://reviews.apache.org/r/48738/diff/1/?file=1420216#file1420216line262>
> >
> > I think it's better to put assertions into awaitility, like this
> > 
> > Awaitility...until(() -> assertEquals(1, r.size())
> > 
> > Although I guess in this case you are using >=, rather than ==. But why 
> > is that? Can't you make an assertion about exactly what size the region 
> > should be?

Good point...Done.


- anilkumar


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


On June 15, 2016, 5:42 p.m., anilkumar gingade wrote:
> 
> ---
> 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.
> 
> 
> 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 
>   
> ge

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

2016-06-15 Thread 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)

2016-06-15 Thread 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)

2016-06-15 Thread 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: M3 status?

2016-06-15 Thread Anilkumar Gingade

GEODE-1493
Its not assigned to anyone...Someone with gradle/build experience can pick
this upDoesn't seems to be a stopper for M3.

GEODE-835
In progress, kirk can comment on this.

-Anil.



On Wed, Jun 15, 2016 at 9:48 AM, Gregory Chase  wrote:

> Should GEODE-33 be broken up into specific tickets?
>
> What do we want examples for?
>
> This might be easier for many of the expert users to actually make
> contributions.
>
> -Greg
>
> On Wed, Jun 15, 2016 at 9:40 AM, Anthony Baker  wrote:
>
> > Hi I reviewed the JIRA’s tagged for the M3 release.  The good news is
> that
> > we’ve fixed 180 issues!  Here are the remaining open issues:
> >
> > GEODE-33: Project examples
> > GEODE-835: joptsimple replacement
> > GEODE-840: CI failure in
> > DistributedAckPersistentRegionCCEOffHeapDUnitTest.testTombstones
> > GEODE-1493: gemfire.properties default value for config dir
> >
> > Any sense for when these issues will be resolved?  Which ones are
> required
> > for M3?
> >
> > Anthony
> >
> >
>
>
> --
> 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/
>

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

2016-06-10 Thread 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

2016-06-10 Thread 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

2016-06-09 Thread 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 48445: GEODE-11: Adding stats for lucene documents, files, and chunks

2016-06-09 Thread anilkumar gingade


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


Fix it, then Ship it!




Ship It!


geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 (line 91)
<https://reviews.apache.org/r/48445/#comment201941>

Since we are creating the regions here; do we need to call region size?



geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
 (line 108)
<https://reviews.apache.org/r/48445/#comment201944>

Will it be a good idea to move it to parent class (LuceneIndexIml)? the 
stats will be same across multiple impletmentations (replicated, partition, 
others), right?



geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStats.java
 (line 33)
<https://reviews.apache.org/r/48445/#comment201949>

Sorry if i am too late to comment on this...

I think we should make stats public...We should have public APIs on 
LuceneIndex that returns LuceneIndexStats (define interface with helper 
methods)...
User could use this in their applications, if needed...


- anilkumar gingade


On June 8, 2016, 9:44 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48445/
> ---
> 
> (Updated June 8, 2016, 9:44 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Using the new stat suppliers added with GEODE-1494 to sample useful
> lucene statistics:
>  * Number of documents
>  * Number of files
>  * Number of chunks
>  * Number of bytes
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  8fe5fac7313d647435c4931dcb27d99160f5a49b 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
>  c75148acc83ef3823ca475a10862ac0a9ce0dc44 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStats.java
>  8dd34a4fea7b6fa83cf4b0e62bd9fd170c7c8ced 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/filesystem/FileSystemStats.java
>  1f609fd53487c6c6070a11c5cff039ab1900c322 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  88631b842b50d0b3d6367198e3e1c44be958ea4e 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java
>  07780ca06a297851c8ff4cb498a09f726a0785d5 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexStatsJUnitTest.java
>  3e6d44c2967973cc5e0aee219f79ef5d11ef1b9c 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImplJUnitTest.java
>  6004623b22ab36e3b24f9b7de3423fe776f07586 
> 
> Diff: https://reviews.apache.org/r/48445/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

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

2016-06-08 Thread 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

2016-06-07 Thread 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.

2016-06-06 Thread 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.

2016-06-03 Thread anilkumar gingade


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

(Updated June 4, 2016, 1:20 a.m.)


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


Changes
---

Added Unit test. Added missing braces for if conditions...


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.

2016-06-03 Thread 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.

2016-06-03 Thread 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.

2016-06-03 Thread 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  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 
> 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 
> > 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 
> 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 
> > 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.

2016-06-03 Thread 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 
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 
> 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 
> > 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  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  wrote:
> > >>
> > >> > +1 for being more explicit with the "And" conjunction
> > >> >
> > >> > -Kirk
> > >> >
> > >> >
> > >> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker 
> > >> 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...

Devs, Thanks for the help and pointers...

-Anil.


On Thu, Jun 2, 2016 at 2:49 PM, Udo Kohlmeyer  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 
>> 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  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 
>>>> 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()).

2016-06-02 Thread 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.

2016-06-02 Thread 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...

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

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.

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 
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  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  wrote:
>>
>> > +1 for being more explicit with the "And" conjunction
>> >
>> > -Kirk
>> >
>> >
>> > On Tue, Apr 12, 2016 at 5:25 PM, Anthony Baker 
>> 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 
>> >> wrote:
>> >>
>> >> *New attribute:* "forwardEvictionExpirationEvents()" (Any alternate
>> >> names?).
>> >>
>> >>
>> >>
>> >
>>
>
>

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

2016-05-25 Thread 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

2016-05-23 Thread 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()).

2016-05-23 Thread 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

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

2016-05-23 Thread anilkumar gingade



> On May 23, 2016, 3:54 p.m., Jason Huynh wrote:
> > geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexMaintenanceIntegrationTest.java,
> >  line 120
> > <https://reviews.apache.org/r/47686/diff/1/?file=1390286#file1390286line120>
> >
> > is this supposed to be commented out?

Good catch...Its not supposed to be commented...Uploaded the latest changes for 
review.


- anilkumar


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


On May 21, 2016, 12:57 a.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/47686/
> ---
> 
> (Updated May 21, 2016, 12:57 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
> 
>

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

2016-05-23 Thread anilkumar gingade


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

(Updated May 23, 2016, 11:56 p.m.)


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


Changes
---

Removed debug messages from the test.


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/test/java/com/gemstone/gemfire/cache/asyncqueue/AsyncEventQueueEvictionAndExpirationJUnitTest.java
 5efac05 

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


Testing
---

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


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

2016-05-20 Thread 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.

2016-05-20 Thread 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


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


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



> 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