Review Request 53752: Removing the Flaky Tag

[nabarun nag]

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

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

This issue was reported in CI monitoring.
More investigation of the failure logs led to the following findings.
1. During test setup VM3 is missing.
2. Also the log show [setup] START TEST 
WanAutoDiscoveryDUnitTest.test_RingTopology instead of [setup] START TEST 
WanAutoDiscoveryDUnitTest.test_NY_Recognises_TK_AND_HK_Simultaneously
3. By evaluating the stacktrace we see that NPE  when we force 
async[2].getReturnValue() to be null. It the return value of  
WANTestBase.createSecondLocator(1, lnLocPort1) which simple returns an port 
number which is not in use. There is an infinite while loop which breaks only 
if it finds a port not in use.

IMO  we remove the flaky tag and monitor the test. Please do let me know if you 
can find an explanation for this failure.


Diffs
-

  
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/misc/WanAutoDiscoveryDUnitTest.java
 388760e 

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


Testing
---

Ran it for multiple iterations.


Thanks,

nabarun nag

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

[Nabarun Nag]

spotlessApply added to DiskSpaceLimitIntegrationTest.java and pushed to
develop.

- local build was successful with no error.

On Tue, Nov 8, 2016 at 8:06 AM Nabarun Nag <n...@pivotal.io> wrote:

> Fixing it.
> On Tue, Nov 8, 2016 at 7:48 AM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
> See <https://builds.apache.org/job/Geode-nightly/647/changes>
>
> Changes:
>
> [upthewaterspout] Adding a geode-benchmark project with support for
> running jmh benchmarks
>
> [upthewaterspout] GEODE-1985 Removing some string comparisons in the
> AttributesDescriptor
>
> [upthewaterspout] GEODE-1985: Updating the SAFE_QUERY_TIME after updating
> indexes
>
> [jiliao] GEODE-2079: mark the test as flaky
>
> [ukohlmeyer] GEODE-2017: removal of nonPRSingleHop stat in client
>
> [ukohlmeyer] GEODE-1874: Changed setNextNeighbor to not create HashMap for
> every p2p
>
> [ukohlmeyer] GEODE-1874: Changed setNextNeighbor to not create HashMap for
> every p2p
>
> [ukohlmeyer] GEODE-1874: Changed setNextNeighbor to not create HashMap for
> every p2p
>
> [ukohlmeyer] GEODE-1874: Changed setNextNeighbor to not create HashMap for
> every p2p
>
> [ukohlmeyer] GEODE-1874: Checkin after code formatting refactor
>
> [ukohlmeyer] GEODE-1874: Fix formatting
>
> [Anil] GEODE-2064: Added check for system shutdown while handlling connect
>
> [nnag] GEODE-2063: Increased the timeout on async thread join
>
> [dschneider] GEODE-1971: fix shutDownAll hang
>
> [eshu] GEODE-2077: Throw appropriate exceptions when get op in a
> transaction
>
> [klund] GEODE-2082: fix flakiness in sameKeepsOneFile
>
> [klund] GEODE-2082: rename aboveZeroKeepsAtLeastOneFile to
>
> --
> [...truncated 519 lines...]
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-cq:processTestResources
> :geode-cq:testClasses
> :geode-cq:checkMissedTests
> :geode-cq:spotlessJavaCheck
> :geode-cq:spotlessCheck
> :geode-cq:test
> :geode-cq:check
> :geode-cq:build
> :geode-cq:distributedTest
> :geode-cq:flakyTest
> :geode-cq:integrationTest
> :geode-json:assemble
> :geode-json:compileTestJava UP-TO-DATE
> :geode-json:processTestResources UP-TO-DATE
> :geode-json:testClasses UP-TO-DATE
> :geode-json:checkMissedTests UP-TO-DATE
> :geode-json:spotlessJavaCheck
> :geode-json:spotlessCheck
> :geode-json:test UP-TO-DATE
> :geode-json:check
> :geode-json:build
> :geode-json:distributedTest UP-TO-DATE
> :geode-json:flakyTest UP-TO-DATE
> :geode-json:integrationTest UP-TO-DATE
> :geode-junit:javadoc
> :geode-junit:javadocJar
> :geode-junit:sourcesJar
> :geode-junit:signArchives SKIPPED
> :geode-junit:assemble
> :geode-junit:compileTestJava
> :geode-junit:processTestResources UP-TO-DATE
> :geode-junit:testClasses
> :geode-junit:checkMissedTests
> :geode-junit:spotlessJavaCheck
> :geode-junit:spotlessCheck
> :geode-junit:test
> :geode-junit:check
> :geode-junit:build
> :geode-junit:distributedTest
> :geode-junit:flakyTest
> :geode-junit:integrationTest
> :geode-lucene:assemble
> :geode-lucene:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-lucene:processTestResources
> :geode-lucene:testClasses
> :geode-lucene:checkMissedTests
> :geode-lucene:spotlessJavaCheck
> :geode-lucene:spotlessCheck
> :geode-lucene:test
> :geode-lucene:check
> :geode-lucene:build
> :geode-lucene:distributedTest
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources UP-TO-DATE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-pulse:assemble
> :geode-pulse:compileTestJavaNote: <
> https://builds.apache.org/job/Geode-nightly/ws/geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/ui/PulseAbstractTest.java>
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-pulse:processTestResource

Re: more spotless problems on Windows

[Nabarun Nag]

@Jared, sure I will verify the branch when I'm at my home windows
workstation. (Creating a AMI instance consumes a lot of time).

I will be let you know of the results asap.

Regards
Naba

On Fri, Nov 4, 2016 at 1:42 PM Jared Stewart <jstew...@pivotal.io> wrote:

> @Naba
>
> I pushed the proposed changes to a branch here:
> https://github.com/jaredjstewart/incubator-geode/tree/windowsLF <
> https://github.com/jaredjstewart/incubator-geode/tree/windowsLF>
>
> Can you see if you still have the same problem when you check out this
> branch?
>
> > On Nov 4, 2016, at 12:07 PM, Bruce Schuchardt <bschucha...@pivotal.io>
> wrote:
> >
> > Udo and I tried that & it didn't work.  Maybe you'll have better luck.
> >
> > Le 11/4/2016 à 11:59 AM, Jared Stewart a écrit :
> >> From the spotless devs:
> >>
> >> Git is not a pure content store, it mucks with line endings. Regardless
> of what you check-in, it will store your files with unix line endings in
> the repo.
> >>
> >> Then, when you checkout, it will modify the line endings to suit your
> platform. Unless you add a .gitattributes file to tell git "forget the
> platform, do what this file says".
> >>
> >> Remove lineEndings 'UNIX' in your build.gradle [Jared - we should put
> ‘GIT_ATTRIBUTES’ in its place], and add a .gitattributes file in your root
> directory with the content * text eol=lf and your problem will be fixed.
> >>
> >>
> >>
> >>> On Nov 4, 2016, at 10:48 AM, Nabarun Nag <n...@pivotal.io> wrote:
> >>>
> >>> Thank you Jared. I wanted to confirm that this was not an isolated
> incident
> >>> specific to my machine.
> >>>
> >>> Regards
> >>> Naba
> >>>
> >>> On Fri, Nov 4, 2016 at 10:45 AM Jared Stewart <jstew...@pivotal.io>
> wrote:
> >>>
> >>>> @Naba,
> >>>>
> >>>> I filed a bug report with Spotless this morning.  The Spotless devs
> have
> >>>> been very responsive so far in my experience, hopefully this will be
> fixed
> >>>> soon.
> >>>>
> >>>>> On Nov 4, 2016, at 10:35 AM, Nabarun Nag <n...@pivotal.io> wrote:
> >>>>>
> >>>>> @Udo, I confirmed that this is not limited to my windows 10
> environment.
> >>>> I
> >>>>> ran  the steps on a Windows Server 2016 AMI instance and the same
> error
> >>>>> occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]
> >>>>>
> >>>>> I wanted to know if there is a mandate on what the value of
> >>>>> core.autocrlf should
> >>>>> be set to on a windows machine for geode dev work. For my experiments
> >>>> value
> >>>>> of core.autocrlf was set to true. [recommended for cross platform
> >>>>> development]
> >>>>>
> >>>>> Regards
> >>>>> Naba
> >>>>>
> >>>>>
> >>>>> On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag <n...@pivotal.io> wrote:
> >>>>>
> >>>>>> @Jared
> >>>>>> I ran ./gradlew spotlessApply on the Windows 10 machine using git
> bash
> >>>>>> this is what has happened.
> >>>>>> NOTE: I started the below steps on a fresh git clone of the open
> side.
> >>>>>> [Steps:
> >>>>>> 1.  git clone
> >>>> https://git-wip-us.apache.org/repos/asf/incubator-geode.git
> >>>>>> open
> >>>>>> 2. cd open
> >>>>>> 3. git checkout -b develop origin/develop]
> >>>>>>
> >>>>>> *Step 1. ./gradlew clean build -Dskip.tests=true*
> >>>>>>
> >>>>>> FAILURE: Build failed with an exception.
> >>>>>>
> >>>>>> * What went wrong:
> >>>>>> Execution failed for task ':geode-core:spotlessJavaCheck'.
> >>>>>>> Format violations were found. Run 'gradlew spotlessApply' to fix
> them.
> >>>>>>
> >>>>
> geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
> >>>>>>
> >>>>
> geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
> >>>>>>
> >>>>
> geode-core\src\

Re: more spotless problems on Windows

[Nabarun Nag]

@Udo, I confirmed that this is not limited to my windows 10 environment. I
ran  the steps on a Windows Server 2016 AMI instance and the same error
occurred in the AMI too. [source checkout time 4th Nov 10:00AM PST]

I wanted to know if there is a mandate on what the value of
core.autocrlf should
be set to on a windows machine for geode dev work. For my experiments value
of core.autocrlf was set to true. [recommended for cross platform
development]

Regards
Naba


On Thu, Nov 3, 2016 at 10:18 PM Nabarun Nag <n...@pivotal.io> wrote:

> @Jared
> I ran ./gradlew spotlessApply on the Windows 10 machine using git bash
> this is what has happened.
> NOTE: I started the below steps on a fresh git clone of the open side.
> [Steps:
> 1.  git clone https://git-wip-us.apache.org/repos/asf/incubator-geode.git
> open
> 2. cd open
> 3. git checkout -b develop origin/develop]
>
> *Step 1. ./gradlew clean build -Dskip.tests=true*
>
> FAILURE: Build failed with an exception.
>
> * What went wrong:
> Execution failed for task ':geode-core:spotlessJavaCheck'.
> > Format violations were found. Run 'gradlew spotlessApply' to fix them.
>
> geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java
>
> geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java
>
> geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java
>
> geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java
>
> geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java
>
>
> *Step 2: ./gradlew spotlessApply*
>
> BUILD SUCCESSFUL
>
> Total time: 12.728 secs
>
>
> *Step 3: git status*
>
>  modified:
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
> modified:
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
> modified:
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
> modified:
> geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
> modified:
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>
>
> *Step 4 : git add .*
> warning: LF will be replaced by CRLF in
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java.
> The file will have its original line endings in your working directory.
> warning: LF will be replaced by CRLF in
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java.
> The file will have its original line endings in your working directory.
> warning: LF will be replaced by CRLF in
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java.
> The file will have its original line endings in your working directory.
> warning: LF will be replaced by CRLF in
> geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java.
> The file will have its original line endings in your working directory.
> warning: LF will be replaced by CRLF in
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java.
> The file will have its original line endings in your working directory.
>
>
> *Step 5: git status*
> On branch develop
> Your branch is up-to-date with 'origin/develop'.
> nothing to commit, working tree clean
>
>
> *Step 6: ./gradlew clean build -Dskip.tests=true*
> BUILD SUCCESSFUL
>
> Total time: 5 mins 28.64 secs
>
> NOTE: This happens only the first time. I did run the above steps,couple
> of times on  fresh checkouts and I was able to reproduce it every time.
>
> However, after running spotlessApply and git add . the first time, the
> spotless errors do not reoccur on subsequent builds.
>
> I will try running this on other machines and check if this occurs in
> other windows environments.
>
>
> Regards
> Naba
>
> On Thu, Nov 3, 2016 at 4:25 PM Udo Kohlmeyer <ukohlme...@pivotal.io>
> wrote:
>
> @Jared, I mailed with the Spotless project devs and they recommend using
> .gitattributes. But maybe @Naba's problem is Windows10 related... Who
> knows..
>
> --Udo
>
>
> On 4/11/16 10:16 am, Jared Stewart wrote:
> > The only Windows machine I have is running Windows 8, and I am unable to
> reproduce this on that machine.  I don’t think .gitattributes would affect
> this, since we have already configured spotless to always use Uni

Re: more spotless problems on Windows

[Nabarun Nag]

@Jared
I ran ./gradlew spotlessApply on the Windows 10 machine using git bash this
is what has happened.
NOTE: I started the below steps on a fresh git clone of the open side.
[Steps:
1.  git clone https://git-wip-us.apache.org/repos/asf/incubator-geode.git
open
2. cd open
3. git checkout -b develop origin/develop]

*Step 1. ./gradlew clean build -Dskip.tests=true*

FAILURE: Build failed with an exception.

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

geode-core\src\main\java\org\apache\geode\internal\statistics\StatArchiveReader.java

geode-core\src\test\java\org\apache\geode\cache\query\dunit\PdxLocalQueryVersionedClassDUnitTest.java

geode-core\src\test\java\org\apache\geode\internal\cache\execute\ClientServerFunctionExecutionDUnitTest.java

geode-core\src\test\java\org\apache\geode\internal\cache\functions\TestFunction.java

geode-core\src\test\java\org\apache\geode\internal\statistics\StatArchiveWithMissingResourceTypeRegressionTest.java


*Step 2: ./gradlew spotlessApply*

BUILD SUCCESSFUL

Total time: 12.728 secs


*Step 3: git status*

 modified:
geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
modified:
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
modified:
geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
modified:
geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
modified:
geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java


*Step 4 : git add .*
warning: LF will be replaced by CRLF in
geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in
geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in
geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java.
The file will have its original line endings in your working directory.
warning: LF will be replaced by CRLF in
geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java.
The file will have its original line endings in your working directory.


*Step 5: git status*
On branch develop
Your branch is up-to-date with 'origin/develop'.
nothing to commit, working tree clean


*Step 6: ./gradlew clean build -Dskip.tests=true*
BUILD SUCCESSFUL

Total time: 5 mins 28.64 secs

NOTE: This happens only the first time. I did run the above steps,couple of
times on  fresh checkouts and I was able to reproduce it every time.

However, after running spotlessApply and git add . the first time, the
spotless errors do not reoccur on subsequent builds.

I will try running this on other machines and check if this occurs in other
windows environments.


Regards
Naba

On Thu, Nov 3, 2016 at 4:25 PM Udo Kohlmeyer <ukohlme...@pivotal.io> wrote:

> @Jared, I mailed with the Spotless project devs and they recommend using
> .gitattributes. But maybe @Naba's problem is Windows10 related... Who
> knows..
>
> --Udo
>
>
> On 4/11/16 10:16 am, Jared Stewart wrote:
> > The only Windows machine I have is running Windows 8, and I am unable to
> reproduce this on that machine.  I don’t think .gitattributes would affect
> this, since we have already configured spotless to always use Unix line
> endings.
> >
> > Naba - Can you run ‘./gradlew spotlessApply’ and push the results to a
> branch so I can see what Spotless was complaining about?
> >
> >> On Nov 3, 2016, at 4:09 PM, Udo Kohlmeyer <u...@apache.org> wrote:
> >>
> >> I think we seriously have to look at using .gitattributes for this...
> >>
> >> As I initially said, it should be a no brainer.. it should just
> automatically just work.
> >>
> >> --Udo
> >>
> >>
> >> On 4/11/16 9:00 am, Bruce Schuchardt wrote:
> >>> It's been working on my Windows 7 machine under a cygwin shell.   I
> just ran it again using "clean bulid -Dskip.tests=true" from the root Geode
> directory on the develop branch.
> >>>
> >>> Run spotlessApply and let us know how it modified the files.
> >>>
> >>>
> >>> Le 11/3/20

Re: more spotless problems on Windows

[Nabarun Nag]

I tested gradlew build on a windows 10 machine to test the spotless feature.

Steps:
1.  git clone https://git-wip-us.apache.org/repos/asf/incubator-geode.git
open
2. cd open
3. git checkout -b develop origin/develop
4.  ./gradlew clean build -Dskip.tests=true

The build failed with multiple formatting error on each file.

In my opinion the issue still exists. It will be awesome if someone else
can verify if the issue still exists by running the build steps on a
different windows machine.

Regards
Nabarun

On Mon, Oct 24, 2016 at 3:50 PM Bruce Schuchardt 
wrote:

> The lineEndings setting works great.  I've pushed the change to develop
>
> On Mon, Oct 24, 2016 at 3:47 PM, Dan Smith  wrote:
>
> > I think we have a fix for the spotless line ending issue on windows;
> Bruce
> > will check it in shortly:
> >
> > diff --git a/build.gradle b/build.gradle
> > index a734e05..6e82433 100755
> > --- a/build.gradle
> > +++ b/build.gradle
> > @@ -88,6 +88,7 @@ subprojects {
> >
> >apply plugin: "com.diffplug.gradle.spotless"
> >spotless {
> > +lineEndings = 'unix';
> >  java {
> >eclipseFormatFile
> > "${rootProject.projectDir}/etc/eclipse-java-google-style.xml"
> >
> >
> > On Mon, Oct 24, 2016 at 2:50 PM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> > > Running geode-core:spotlessCheck complains that all of the .java files
> > > have format violations
> > >
> > > * What went wrong:
> > > Execution failed for task ':geode-core:spotlessJavaCheck'.
> > > > Format violations were found. Run 'gradlew spotlessApply' to fix
> them.
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\GFConne
> > > ctionFactoryImpl.java
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\
> > GFConnectionImpl.java
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\spi\JCA
> > > LocalTransaction.java
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\spi\JCA
> > > ManagedConnection.java
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\spi\JCA
> > > ManagedConnectionFactory.java
> > > geode-core\src\jca\java\org\apache\geode\internal\ra\spi\JCA
> > > ManagedConnectionnMetaData.java
> > > etc.
> > >
> > > Until this is fixed I can't validate that the changes I check in
> conform
> > > to the formatting rules.
> > >
> >
>

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

[Nabarun Nag]

I will get this fixed.

On Thu, Nov 3, 2016 at 8:54 AM Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> Changes:
>
> [kmiller] GEODE-2050 Remove doc of statistics no longer present
>
> [kmiller] GEODE-2050 Add docs for new membership svc statistics
>
> [bschuchardt] GEODE-2059 client SSL handshake attempts do not time out
>
> [nnag] GEODE-2062:Added new tests for PDX queries, order by queries and
> queries
>
> [nnag] GEODE-2062: Removing a comment.
>
> [nnag] GEODE-1932: Synchronized the test functions
>
> --
> [...truncated 493 lines...]
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-cq:processTestResources
> :geode-cq:testClasses
> :geode-cq:checkMissedTests
> :geode-cq:spotlessJavaCheck
> :geode-cq:spotlessCheck
> :geode-cq:test
> :geode-cq:check
> :geode-cq:build
> :geode-cq:distributedTest
> :geode-cq:flakyTest
> :geode-cq:integrationTest
> :geode-json:assemble
> :geode-json:compileTestJava UP-TO-DATE
> :geode-json:processTestResources UP-TO-DATE
> :geode-json:testClasses UP-TO-DATE
> :geode-json:checkMissedTests UP-TO-DATE
> :geode-json:spotlessJavaCheck
> :geode-json:spotlessCheck
> :geode-json:test UP-TO-DATE
> :geode-json:check
> :geode-json:build
> :geode-json:distributedTest UP-TO-DATE
> :geode-json:flakyTest UP-TO-DATE
> :geode-json:integrationTest UP-TO-DATE
> :geode-junit:javadoc
> :geode-junit:javadocJar
> :geode-junit:sourcesJar
> :geode-junit:signArchives SKIPPED
> :geode-junit:assemble
> :geode-junit:compileTestJava
> :geode-junit:processTestResources UP-TO-DATE
> :geode-junit:testClasses
> :geode-junit:checkMissedTests
> :geode-junit:spotlessJavaCheck
> :geode-junit:spotlessCheck
> :geode-junit:test
> :geode-junit:check
> :geode-junit:build
> :geode-junit:distributedTest
> :geode-junit:flakyTest
> :geode-junit:integrationTest
> :geode-lucene:assemble
> :geode-lucene:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-lucene:processTestResources
> :geode-lucene:testClasses
> :geode-lucene:checkMissedTests
> :geode-lucene:spotlessJavaCheck
> :geode-lucene:spotlessCheck
> :geode-lucene:test
> :geode-lucene:check
> :geode-lucene:build
> :geode-lucene:distributedTest
> :geode-lucene:flakyTest
> :geode-lucene:integrationTest
> :geode-old-client-support:assemble
> :geode-old-client-support:compileTestJava
> :geode-old-client-support:processTestResources UP-TO-DATE
> :geode-old-client-support:testClasses
> :geode-old-client-support:checkMissedTests
> :geode-old-client-support:spotlessJavaCheck
> :geode-old-client-support:spotlessCheck
> :geode-old-client-support:test
> :geode-old-client-support:check
> :geode-old-client-support:build
> :geode-old-client-support:distributedTest
> :geode-old-client-support:flakyTest
> :geode-old-client-support:integrationTest
> :geode-pulse:assemble
> :geode-pulse:compileTestJavaNote: <
> https://builds.apache.org/job/Geode-nightly/ws/geode-pulse/src/test/java/org/apache/geode/tools/pulse/tests/ui/PulseAbstractTest.java>
> uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-pulse:processTestResources
> :geode-pulse:testClasses
> :geode-pulse:checkMissedTests
> :geode-pulse:spotlessJavaCheck
> :geode-pulse:spotlessCheck
> :geode-pulse:test
> :geode-pulse:check
> :geode-pulse:build
> :geode-pulse:distributedTest
> :geode-pulse:flakyTest
> :geode-pulse:integrationTest
> :geode-rebalancer:assemble
> :geode-rebalancer:compileTestJava
> :geode-rebalancer:processTestResources UP-TO-DATE
> :geode-rebalancer:testClasses
> :geode-rebalancer:checkMissedTests
> :geode-rebalancer:spotlessJavaCheck
> :geode-rebalancer:spotlessCheck
> :geode-rebalancer:test
> :geode-rebalancer:check
> :geode-rebalancer:build
> :geode-rebalancer:distributedTest
> :geode-rebalancer:flakyTest
> :geode-rebalancer:integrationTest
> :geode-wan:assemble
> :geode-wan:compileTestJavaNote: Some input files use or override a
> deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
>
> :geode-wan:processTestResources
> :geode-wan:testClasses
> :geode-wan:checkMissedTests
> :geode-wan:spotlessJavaCheck
> :geode-wan:spotlessCheck
> :geode-wan:test
> :geode-wan:check
> :geode-wan:build
> :geode-wan:distributedTest
> :geode-wan:flakyTest
> :geode-wan:integrationTest
> :geode-web:assemble
> :geode-web:compileTestJavaNote: Some input files use or override a
> deprecated API.
> 

Review Request 53401: GEODE-1932: Protected use of global variables

[nabarun nag]

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

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

* As per the stacktrace in the ticket we could see that the failure was 
happening because the test was getting the wrong result for the function 
execution.
* In the TestFunction executeFunctionReexecuteExceptionOnServer we could see 
that it was using global counter static variable retryCount.
* This global variable retryCount was also used by 
executeFunctionReexecuteException.
* So if these functions are invoked parallely we have a chance that these 
counter global variable may have corrupted values.
* Hence we gave both the test functions their own retry count global static 
variable, they dont share retry count anymore.
* Also we made these test functions synchronized so that reexecution by 
different threads do no corrupt the global static variables.
* The test function executeFunctionReexecuteExceptionOnServer stops 
re-execution when the retryCount >= 5 but in the test we validate that 
retryCount == 5. This was made uniform by making the test validate that 
retryCount >= 5 
* Added more information in the assertEquals, which now output the received and 
expected values when there is an assertion failure.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
 d217792 
  
geode-core/src/test/java/org/apache/geode/internal/cache/functions/TestFunction.java
 f9f05ab 

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


Testing
---

precheckin
IntelliJ multiple executions.


Thanks,

nabarun nag

Re: Review Request 53345: Adding new PDX , order by and Index Query tests to the open side

[nabarun nag]

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




geode-core/src/test/java/org/apache/geode/cache/query/dunit/HashIndexDUnitTest.java
 (line 74)
<https://reviews.apache.org/r/53345/#comment223984>

This was to trick precheckin to accept my patch.


- nabarun nag


On Nov. 1, 2016, 6:22 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53345/
> ---
> 
> (Updated Nov. 1, 2016, 6:22 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, Dan 
> Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added new tests for PDX queries, order by queries and queries using indexes.
> 
> * PDXInstance and PDXFactoryImpl were used to validate multiple class version 
> test rather than writing dummy PDX classes
> * JUnit4CacheTestCase was used instead of Junit3 elements.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/HashIndexDUnitTest.java
>  78b092f 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/JUnit4PDXQueryTestBase.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/OrderByPartitionedDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PDXQueryTestBase.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxGroupByPartitionedQueryDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxQueryDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PortfolioPdxVersion.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/PositionPdxVersion.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53345/diff/
> 
> 
> Testing
> ---
> 
> Precheck-in passed
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Review Request 53345: Adding new PDX , order by and Index Query tests to the open side

[nabarun nag]

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

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


Repository: geode


Description
---

Added new tests for PDX queries, order by queries and queries using indexes.

* PDXInstance and PDXFactoryImpl were used to validate multiple class version 
test rather than writing dummy PDX classes
* JUnit4CacheTestCase was used instead of Junit3 elements.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/HashIndexDUnitTest.java
 78b092f 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/JUnit4PDXQueryTestBase.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/OrderByPartitionedDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PDXQueryTestBase.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxGroupByPartitionedQueryDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxLocalQueryVersionedClassDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PdxQueryDUnitTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PortfolioPdxVersion.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/PositionPdxVersion.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryIndexDUnitTest.java
 PRE-CREATION 

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


Testing
---

Precheck-in passed


Thanks,

nabarun nag

Re: [DISCUSS] Graduation

[Nabarun Nag]

+1
On Wed, Oct 26, 2016 at 12:07 PM Mark Bretl  wrote:

> +1
>
> On Wed, Oct 26, 2016 at 12:04 PM, Ashvin A  wrote:
>
> > +1
> >
> > On Tue, Oct 25, 2016 at 5:25 PM, Roman Shaposhnik 
> wrote:
> >
> > >  inactive
> > >   microsoft.com (Ashvin)
> > >
> >
> > :-(
> >
>

Review Request 53026: GEODE-502: Startup timeout increased to 2min in DUnitLauncher

[nabarun nag]

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

Review request for geode and Dan Smith.


Repository: geode


Description
---

* While creating VMs for the DUnit tests sometimes GC may kick in
* But the test framework requires the VMs to be ready within 30 seconds.
* So we have increased the timeout to 2min to account for the time consumed by 
GC
* This is to handle errors in CI running in slower machines.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/test/dunit/standalone/DUnitLauncher.java
 6618d2a 

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


Testing
---

precheck


Thanks,

nabarun nag

Re: Review Request 52805: GEODE-1981: Wrapping user ResultCollector in synchronized wrapper

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Oct. 12, 2016, 8:58 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52805/
> ---
> 
> (Updated Oct. 12, 2016, 8:58 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When executing a function from a client, we can be adding results to the
> result collector from multiple threads. Our docs claim the user should
> not have to synchronize their result collector. One code path was already
> synchronizing on the collector when adding results. However, if the
> function returned an exception we were not synchronizing.
> 
> Adding a SynchronizedResultCollector and wrapping the users collector in
> that to ensure that there will be no unsynchronized access of the result
> collector.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteFunctionOp.java
>  6597b680227fb47492dc973baecffd504d6cdf68 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionSingleHopOp.java
>  51ea8e4fbc64acbbd1165856a2dd09704d63e857 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/ServerFunctionExecutor.java
>  4295898583aff1409bf6acdd84c5a4c8a8709e51 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/ServerRegionFunctionExecutor.java
>  b5bc684e0b29bfc62dd958ccff49d47c2bad36fa 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/execute/util/SynchronizedResultCollector.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/52805/diff/
> 
> 
> Testing
> ---
> 
> Ran the affected test 500 times with this fix. It failed 11 times without it, 
> passed with the fix.
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Review Request 52793: GEODE-1353: Added listeners to slow down the receiver.

[nabarun nag]

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

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

Scenario without the fix:

1. The test creates receivers and senders.
2. It initiates put operation on the sender as an async operation.
3. Immediately it destroys the receivers regions.
4. It assumes that sender must not have completed the transmission because 
receiver region is destroyed.
5. It checks that the sender's queue is not empty

Problem: Its assumption that senders have not completed the transmission before 
the receiver's region is destroyed is wrong. It may have completed the 
transmission and the test fails because sender queues are  empty.


Fix:
We slow down the receivers using addListenerToSleepAfterCreateEvent, hence we 
make sure that the senders are not able to complete the transmission before the 
receiver regions are destroyed. This function was used to solve similar timing 
related bugs in WAN.


* This was done to avoid the need for a very large number of puts.
* When region size is more than 5 it can initiate the destroy region
* While the puts have been reduced to 2000 from 20,000
* This will make sure the queue is not empty.


Diffs
-

  
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
 4db4890 

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


Testing
---

* Precheckin
* 100 Runs on IntelliJ


Thanks,

nabarun nag

Review Request 52789: GEODE-1978: Slowing down the receivers

[nabarun nag]

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

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

Scenario without the fix:

1. The test creates receivers and senders.
2. It initiates put operation on the sender as an async operation.
3. Immediately it destroys the receivers regions.
4. It assumes that sender must not have completed the transmission because 
receiver region is destroyed.
5. It checks that the sender's queue is not empty 


Problem: Its assumption that senders have not completed the transmission before 
the receiver's region is destroyed is wrong. It may have completed the 
transmission and the test fails because sender queues are  empty.

Solution: We slow down the receivers using addListenerToSleepAfterCreateEvent, 
hence we make sure that the senders are not able to complete the transmission 
before the receiver regions are destroyed. This function was used to solve 
similar timing related bugs in WAN.


Diffs
-

  
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/concurrent/ConcurrentWANPropagation_1_DUnitTest.java
 8bfd8e7 

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


Testing
---

* Precheckin
* 100 runs on IntelliJ


Thanks,

nabarun nag

Re: Coding practices/standards

[Nabarun Nag]

+1

On Wed, Oct 12, 2016 at 10:06 AM Dan Smith  wrote:

> +1
>
> This might be a good time to reformat the code since I don't think there
> are too many long lived feature branches outstanding.
>
> -Dan
>
> On Wed, Oct 12, 2016 at 10:00 AM, Jared Stewart 
> wrote:
>
> > I would like to advocate for adding a Checkstyle  > sourceforge.net/> or Spotless 
> > gradle task to our build process to ensure that all code checked in meets
> > the formatting standards described on the wiki <
> https://cwiki.apache.org/
> > confluence/display/GEODE/Code+Style+Guide> (and in the intellij/eclipse
> > formatter xml files in our repository). This will alleviate difficulties
> > reviewing code when whitespace or formatting has changed since all code
> > checked in will already comply with standards.
>

Re: Adding Apache License header to GetRegionsFunctionJUnitTest

[Nabarun Nag]

Hi Mark,

Thank you,

The branch is deleted. And the code was check into the develop branch

On Fri, Oct 7, 2016 at 11:55 AM Mark Bretl <asf.mbr...@gmail.com> wrote:

> Hi Nabarun,
>
> It looks like you added to the 'develop2' branch, did you mean 'develop'
> instead?
>
> --Mark
>
> On Fri, Oct 7, 2016 at 11:50 AM, Nabarun Nag <n...@pivotal.io> wrote:
>
> > Hi,
> >
> > I am adding the license header to this file. Resolving rat issue.
> >
> > Regards
> > Naba
> >
>

Adding Apache License header to GetRegionsFunctionJUnitTest

[Nabarun Nag]

Hi,

I am adding the license header to this file. Resolving rat issue.

Regards
Naba

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

[nabarun nag]

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

Review request for geode, Barry Oglesby, Jason Huynh, Dan Smith, and xiaojian 
zhou.


Repository: geode


Description
---

CompactMapRangeIndex loses track when the same entry is deleted and added 
because after the mapping was removed from the CompactMapRangeIndex it was not 
removed from removedKeyValuesEntries. So when the same entry is reentered, the 
system ends up thinking inplace modification has occured and ends up removing 
the updated new entry, resulting in empty query results for that entry.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactMapRangeIndex.java
 234dfae 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
 b651272 

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


Testing
---

precheck 
Additional tests were written.


Thanks,

nabarun nag

Re: CI bugs

[Nabarun Nag]

 Flaky tags were removed from the following tests after fixes were checked
in:

GEODE-1731
GEODE-1148
GEODE-1364
GEODE-1804
GEODE-1147
GEODE-1384

For now GEODE-1448 remains flaky, even if the receiver port in use issue
was resolved because a pause(1) still remains in the test.
The flaky tag will be removed after an alternative to the pause is found.

Regards
Nabarun


On Tue, Oct 4, 2016 at 5:01 PM Udo Kohlmeyer <ukohlme...@pivotal.io> wrote:

> +1
>
>
> On 5/10/2016 6:28 AM, Nabarun Nag wrote:
> > Hi,
> >
> > I removed the flaky tags from the test in the WAN module. I went through
> > the commits and made sure they had indeed removed the pauses.
> >
> > Please do let me know if I have missed something. Or if these these
> tickets
> > should still be marked flaky.
> >
> > ParallelGatewaySenderOperationsDUnitTest:
> > GEODE-933: Flaky tag was removed - Wait.pause was no longer used.
> >
> > ParallelWANStatsDUnitTest
> > GEODE-977: Was Flaky because stats were being read from the wrong VM
> >
> > Others:
> > GEODE-1066: Wait criterions were replaced with Awaitility, also order of
> > creating cache, regions and senders/receivers were modified.  No
> > wait.pauses were used.
> > GEODE-1147: No wait.pause were present. It was assumed that refactoring
> of
> > the WANTestBase and the code had fixed the issue.
> > GEODE-1148: Flaky tag was removed - Wait.pause was no longer used along
> > with other modifications to make the test stable.
> > GEODE-1207: Stopped WAN Locator Discovery Thread when locator is
> stopped.  No
> > wait.pauses were used.
> > GEODE-1011: Wait.pauses were removed. Code was modified to stabilize it.
> > GEODE-1062: Thread.sleep was removed. Issue was resolved by refactoring
> of
> > WANTestBase.
> > GEODE-1032: Listeners were put in to slow down the receivers. No
> > wait.pauses were used.
> > GEODE-1121: Memory configurations were changed to stabilize the test.  No
> > wait.pauses were used.
> >
> > Regards
> > Nabarun
> >
> >
> > On Tue, Oct 4, 2016 at 11:04 AM Swapnil Bawaskar <sbawas...@pivotal.io>
> > wrote:
> >
> > +1
> >
> > On Tue, Oct 4, 2016 at 10:58 AM, John Blum <jb...@pivotal.io> wrote:
> >
> >> +1
> >>
> >> On Tue, Oct 4, 2016 at 10:11 AM, Kirk Lund <kl...@pivotal.io> wrote:
> >>
> >>> Please don't close flaky tickets or remove FlakyTest category unless
> you
> >>> know of a specific commit revision that makes some timing changes to
> the
> >>> test. Unless you replace all the Thread.sleeps with await() calls it's
> >>> going to fail again when GC occurs during the test. Just because a test
> >>> doesn't fail in 30+ runs, doesn't mean it's not flaky.
> >>>
> >>> ParallelGatewaySenderOperationsDUnitTest has a bunch of these calls:
> >>>
> >>>Wait.pause(2000);
> >>>
> >>> That's pretty much our definition of flaky.
> >>>
> >>> ParallelWANStatsDUnitTest is worse because it has even shorter sleeps:
> >>>
> >>>pause(200);
> >>>
> >>> I'm replacing the sleeps in the ManagementTestBase tests with
> Awaitility
> >>> calls and the tests are dropping from 5 minutes to 30 seconds per dunit
> >>> class. So that's another huge motivator to get rid of these broken
> >> sleeps.
> >>> -Kirk
> >>>
> >>>
> >>> On Sun, Oct 2, 2016 at 7:33 PM, Xiaojian Zhou <gz...@pivotal.io>
> wrote:
> >>>
> >>>> GEODE-933 and GEODE-977 are not reproducible either after run 30+
> >> times.
> >>> So
> >>>> they are not flaky and can be closed for now.
> >>>>
> >>>> On Sat, Oct 1, 2016 at 11:30 PM, Xiaojian Zhou <gz...@pivotal.io>
> >> wrote:
> >>>>> 1011, 1062, 1066, 1147 have been run 30+ times without reproduce. So
> >>> it's
> >>>>> not flaky. I think we can close them. If reproduced someday, we can
> >>>>> re-open.
> >>>>>
> >>>>>
> >>>>> On Sat, Oct 1, 2016 at 5:09 PM, Anthony Baker <aba...@pivotal.io>
> >>> wrote:
> >>>>>> I reviewed a bunch of CI failures today.  I closed out duplicates
> >> and
> >>>>>> added the ‘CI’ label to JIRA tickets that were missing it.  I just
> >>>> posted a
> >>>>>> big review to add the FlakyTest category to bugs with
> >> non-reproducible
> >>>>>> failures—pretty much any CI bug that is currently open.  Your
> >> comments
> >>>> are
> >>>>>> appreciated (I can push a feature branch if that’s easier):
> >>>>>>
> >>>>>> https://reviews.apache.org/r/52468/
> >>>>>>
> >>>>>> I found several open issues where the flaky category had been
> >> removed.
> >>>>>> Can these be marked resolved?
> >>>>>>
> >>>>>> GEODE-933
> >>>>>> GEODE-977
> >>>>>> GEODE-1011
> >>>>>> GEODE-1062
> >>>>>> GEODE-1066
> >>>>>> GEODE-1147
> >>>>>>
> >>>>>> I have a suspicion that the following open issues are actually
> >> fixed.
> >>>>>> Any ideas?
> >>>>>>
> >>>>>> GEODE-1918
> >>>>>> GEODE-1333,1334,1335
> >>>>>>
> >>>>>>
> >>>>>> Anthony
> >>>>>>
> >>>>>>
> >>
> >>
> >> --
> >> -John
> >> 503-504-8657 <(503)%20504-8657>
> >> john.blum10101 (skype)
> >>
>
>

Log related test failures in GEODE

[Nabarun Nag]

   - The following tests are failing on precheck as well as in IntelliJ
   Tests :
   -
   CustomConfigWithCacheIntegrationTest
   

   . cacheLogWriterMessageShouldMatchCustomConfig
   

   - CustomConfigWithLogServiceIntegrationTest
   

   . logEventShouldMatchCustomConfig
   


   With the following error :
   -

   java.lang.AssertionError:
   Expecting:
"CUSTOM: level=DEBUG time=2016/10/04 15:51:11.338 PDT
 message=this is a log statement
   throwable=
   "
   to match pattern:
"CUSTOM: level=DEBUG time=.* message=this is a log statement
   throwable=
   "

Re: Review Request 52398: GEODE-1949: Remove the dependency on quartz from the rebalancer

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Sept. 29, 2016, 10:57 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52398/
> ---
> 
> (Updated Sept. 29, 2016, 10:57 p.m.)
> 
> 
> Review request for geode, Jason Huynh, nabarun nag, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The geode-rebalancer does not need to depend on quartz, it is using
> spring-expression for all of the cron heavy lifting.
> 
> 
> Diffs
> -
> 
>   geode-rebalancer/build.gradle 00c43e4b0dad70fd923a603e63c1976d69b4b3e8 
>   
> geode-rebalancer/src/main/java/org/apache/geode/cache/util/AutoBalancer.java 
> 98c5237df68b31b46b67c4cdc6be4564990f6ae7 
> 
> Diff: https://reviews.apache.org/r/52398/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 52176: GEODE-1926: Modification of peedAhead() function check if heapCopy is successful before adding the key to peekedIds

[nabarun nag]

> On Sept. 22, 2016, 11:02 p.m., Dan Smith wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java,
> >  line 796
> > <https://reviews.apache.org/r/52176/diff/1/?file=1508581#file1508581line796>
> >
> > Minor nit - can't you just write this code like this?
> > 
> > Long currentKey = getCurrentKey();
> > if(currentKey == null) {
> > 
> > Seems less confusing that way.
> 
> nabarun nag wrote:
> I completely agree with this. I was following the way other if 
> comparisons were done in the peekAhead. ->
> 
> while (before(currentKey, getTailKey())
> && (object = getObjectInSerialSenderQueue(currentKey)) == null) {
> 
> I will fix such comparisons in other places too
> 
> Dan Smith wrote:
> Your example above is in a while loop, so it actually is fetching the 
> object on each iteration.

aah!! i assumed the amount of confusion would be same in the comparison within 
an if condition and a while loop. Hence changed it to
object = getObjectInSerialSenderQueue(currentKey);
while (before(currentKey, getTailKey())
&& (object == null)) {
  currentKey = inc(currentKey);
  object = getObjectInSerialSenderQueue(currentKey);
  }
  
I assumed keeping both the functions incrementing current key and fetching the 
object within the loop was a good idea.

Do you think its not a good idea?


- nabarun


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


On Sept. 23, 2016, 9:58 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52176/
> ---
> 
> (Updated Sept. 23, 2016, 9:58 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Eric Shu, Jason Huynh, Dan Smith, 
> and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Before my changes:
> 1. peek calls peekAhead to get the object from the sender queue to be put 
> into the batch for dispatch.
> 2. peekAhead gets the current key for which it is able to get an object back 
> by calling optimalGet.
> 3. It puts that current key into the peekedIds list and returns the object 
> back to peek.
> 4. peek then tries to make a heapcopy and only if it is successful it will 
> put the object into the dispatch batch.
> 5. Here is the issue, now conflation may kick in before peek is able to do 
> heapcopy and that object is removed from the queue and hence the object will 
> not be placed in the dispatch batch. However the the key representing that 
> object in the queue still exist in the PeekedIDs list.
> 6. So now there is an extra key in the peekedIds list.
> 7. Batch is dispatched and now the ack is received, so things need to be 
> removed from the sender queue.
> 8. remove() is called in a for loop with the count set to size of dispatch 
> batch for which ack was received. 
> 9. The remove() operation picks up keys from peekedIds list sequentially and 
> calls remove(key) on the queue.
> 10. Now since the batch size is smaller than the Ids peeked, element will 
> still linger behind after all remove calls are completed.
> 11. so tests which wait for queues to be empty will hang forever.
> 
> Solution:
> Since peek() doesnt have access to the current key but just the object and 
> hence cannot remove it from peekedIDs list, we moved the check for heapcopy 
> into peekAhead. 
> 
> So now only if a successful heap copy is made then only the key will be 
> placed into the peekedIDs list.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
>  a8bb72d 
> 
> Diff: https://reviews.apache.org/r/52176/diff/
> 
> 
> Testing
> ---
> 
> precheck
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Review Request 52176: GEODE-1926: Modification of peedAhead() function check if heapCopy is successful before adding the key to peekedIds

[nabarun nag]

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



I was able to find paralleWANConflationDUnitTest but no 
serialWANConflationDUnitTest in Geode, 
Am I missing something or are serial WAN conflation tests under a different 
class.

- nabarun nag


On Sept. 23, 2016, 9:58 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52176/
> ---
> 
> (Updated Sept. 23, 2016, 9:58 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Eric Shu, Jason Huynh, Dan Smith, 
> and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Before my changes:
> 1. peek calls peekAhead to get the object from the sender queue to be put 
> into the batch for dispatch.
> 2. peekAhead gets the current key for which it is able to get an object back 
> by calling optimalGet.
> 3. It puts that current key into the peekedIds list and returns the object 
> back to peek.
> 4. peek then tries to make a heapcopy and only if it is successful it will 
> put the object into the dispatch batch.
> 5. Here is the issue, now conflation may kick in before peek is able to do 
> heapcopy and that object is removed from the queue and hence the object will 
> not be placed in the dispatch batch. However the the key representing that 
> object in the queue still exist in the PeekedIDs list.
> 6. So now there is an extra key in the peekedIds list.
> 7. Batch is dispatched and now the ack is received, so things need to be 
> removed from the sender queue.
> 8. remove() is called in a for loop with the count set to size of dispatch 
> batch for which ack was received. 
> 9. The remove() operation picks up keys from peekedIds list sequentially and 
> calls remove(key) on the queue.
> 10. Now since the batch size is smaller than the Ids peeked, element will 
> still linger behind after all remove calls are completed.
> 11. so tests which wait for queues to be empty will hang forever.
> 
> Solution:
> Since peek() doesnt have access to the current key but just the object and 
> hence cannot remove it from peekedIDs list, we moved the check for heapcopy 
> into peekAhead. 
> 
> So now only if a successful heap copy is made then only the key will be 
> placed into the peekedIDs list.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
>  a8bb72d 
> 
> Diff: https://reviews.apache.org/r/52176/diff/
> 
> 
> Testing
> ---
> 
> precheck
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Review Request 52176: GEODE-1926: Modification of peedAhead() function check if heapCopy is successful before adding the key to peekedIds

[nabarun nag]

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

(Updated Sept. 23, 2016, 9:58 p.m.)


Review request for geode, Barry Oglesby, Eric Shu, Jason Huynh, Dan Smith, and 
xiaojian zhou.


Repository: geode


Description
---

Before my changes:
1. peek calls peekAhead to get the object from the sender queue to be put into 
the batch for dispatch.
2. peekAhead gets the current key for which it is able to get an object back by 
calling optimalGet.
3. It puts that current key into the peekedIds list and returns the object back 
to peek.
4. peek then tries to make a heapcopy and only if it is successful it will put 
the object into the dispatch batch.
5. Here is the issue, now conflation may kick in before peek is able to do 
heapcopy and that object is removed from the queue and hence the object will 
not be placed in the dispatch batch. However the the key representing that 
object in the queue still exist in the PeekedIDs list.
6. So now there is an extra key in the peekedIds list.
7. Batch is dispatched and now the ack is received, so things need to be 
removed from the sender queue.
8. remove() is called in a for loop with the count set to size of dispatch 
batch for which ack was received. 
9. The remove() operation picks up keys from peekedIds list sequentially and 
calls remove(key) on the queue.
10. Now since the batch size is smaller than the Ids peeked, element will still 
linger behind after all remove calls are completed.
11. so tests which wait for queues to be empty will hang forever.

Solution:
Since peek() doesnt have access to the current key but just the object and 
hence cannot remove it from peekedIDs list, we moved the check for heapcopy 
into peekAhead. 

So now only if a successful heap copy is made then only the key will be placed 
into the peekedIDs list.


Diffs (updated)
-

  
geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
 a8bb72d 

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


Testing
---

precheck


Thanks,

nabarun nag

Re: Review Request 52176: GEODE-1926: Modification of peedAhead() function check if heapCopy is successful before adding the key to peekedIds

[nabarun nag]

> On Sept. 23, 2016, 8:29 p.m., Jason Huynh wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java,
> >  line 796
> > <https://reviews.apache.org/r/52176/diff/1/?file=1508581#file1508581line796>
> >
> > +1 on the less confusing part

sorry about that  copied previous coding style 
(object = optimalGet(currentKey)) == null)


- nabarun


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


On Sept. 22, 2016, 9:46 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52176/
> ---
> 
> (Updated Sept. 22, 2016, 9:46 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Eric Shu, Jason Huynh, Dan Smith, 
> and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Before my changes:
> 1. peek calls peekAhead to get the object from the sender queue to be put 
> into the batch for dispatch.
> 2. peekAhead gets the current key for which it is able to get an object back 
> by calling optimalGet.
> 3. It puts that current key into the peekedIds list and returns the object 
> back to peek.
> 4. peek then tries to make a heapcopy and only if it is successful it will 
> put the object into the dispatch batch.
> 5. Here is the issue, now conflation may kick in before peek is able to do 
> heapcopy and that object is removed from the queue and hence the object will 
> not be placed in the dispatch batch. However the the key representing that 
> object in the queue still exist in the PeekedIDs list.
> 6. So now there is an extra key in the peekedIds list.
> 7. Batch is dispatched and now the ack is received, so things need to be 
> removed from the sender queue.
> 8. remove() is called in a for loop with the count set to size of dispatch 
> batch for which ack was received. 
> 9. The remove() operation picks up keys from peekedIds list sequentially and 
> calls remove(key) on the queue.
> 10. Now since the batch size is smaller than the Ids peeked, element will 
> still linger behind after all remove calls are completed.
> 11. so tests which wait for queues to be empty will hang forever.
> 
> Solution:
> Since peek() doesnt have access to the current key but just the object and 
> hence cannot remove it from peekedIDs list, we moved the check for heapcopy 
> into peekAhead. 
> 
> So now only if a successful heap copy is made then only the key will be 
> placed into the peekedIDs list.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
>  a8bb72d 
> 
> Diff: https://reviews.apache.org/r/52176/diff/
> 
> 
> Testing
> ---
> 
> precheck
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Review Request 52176: GEODE-1926: Modification of peedAhead() function check if heapCopy is successful before adding the key to peekedIds

[nabarun nag]

> On Sept. 22, 2016, 11:02 p.m., Dan Smith wrote:
> > Looks like a good fix for a really complicated issue!
> > 
> > I had a couple of minor nitpicks, below. Also, is there a reason why you 
> > did not remove the code to 
> > ((GatewaySenderEventImpl)object).makeHeapCopyIfOffHeap() in 
> > SerialGatewaySenderQueue.peek? It seems like since you moved the copy to 
> > peekAhead that code is not doing anything anymore?
> > 
> > Is there any way to write at least a unit test for this code?

was updated in a new patch.
review went on an older patch. sorry about that


I assumed peekAhead had already some JUnit tests written for it hence I was 
confident after pre-check and other WANtests passed. I will write few Junit 
tests if they are not present.


> On Sept. 22, 2016, 11:02 p.m., Dan Smith wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java,
> >  line 796
> > <https://reviews.apache.org/r/52176/diff/1/?file=1508581#file1508581line796>
> >
> > Minor nit - can't you just write this code like this?
> > 
> > Long currentKey = getCurrentKey();
> > if(currentKey == null) {
> > 
> > Seems less confusing that way.

I completely agree with this. I was following the way other if comparisons were 
done in the peekAhead. ->

while (before(currentKey, getTailKey())
&& (object = getObjectInSerialSenderQueue(currentKey)) == null) {

I will fix such comparisons in other places too


> On Sept. 22, 2016, 11:02 p.m., Dan Smith wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java,
> >  line 778
> > <https://reviews.apache.org/r/52176/diff/1/?file=1508581#file1508581line778>
> >
> > valueOf is uneccessary here.

was updated in a new patch.
review went on an older patch. sorry about that


- nabarun


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


On Sept. 22, 2016, 9:46 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52176/
> ---
> 
> (Updated Sept. 22, 2016, 9:46 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Eric Shu, Jason Huynh, Dan Smith, 
> and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Before my changes:
> 1. peek calls peekAhead to get the object from the sender queue to be put 
> into the batch for dispatch.
> 2. peekAhead gets the current key for which it is able to get an object back 
> by calling optimalGet.
> 3. It puts that current key into the peekedIds list and returns the object 
> back to peek.
> 4. peek then tries to make a heapcopy and only if it is successful it will 
> put the object into the dispatch batch.
> 5. Here is the issue, now conflation may kick in before peek is able to do 
> heapcopy and that object is removed from the queue and hence the object will 
> not be placed in the dispatch batch. However the the key representing that 
> object in the queue still exist in the PeekedIDs list.
> 6. So now there is an extra key in the peekedIds list.
> 7. Batch is dispatched and now the ack is received, so things need to be 
> removed from the sender queue.
> 8. remove() is called in a for loop with the count set to size of dispatch 
> batch for which ack was received. 
> 9. The remove() operation picks up keys from peekedIds list sequentially and 
> calls remove(key) on the queue.
> 10. Now since the batch size is smaller than the Ids peeked, element will 
> still linger behind after all remove calls are completed.
> 11. so tests which wait for queues to be empty will hang forever.
> 
> Solution:
> Since peek() doesnt have access to the current key but just the object and 
> hence cannot remove it from peekedIDs list, we moved the check for heapcopy 
> into peekAhead. 
> 
> So now only if a successful heap copy is made then only the key will be 
> placed into the peekedIDs list.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderQueue.java
>  a8bb72d 
> 
> Diff: https://reviews.apache.org/r/52176/diff/
> 
> 
> Testing
> ---
> 
> precheck
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Review Request 51734: GEODE-1864: CompactMapRangeIndex not updating old keys properly

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Sept. 21, 2016, 4 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51734/
> ---
> 
> (Updated Sept. 21, 2016, 4 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Old keys that are no longer part of a new map, should be removed from the 
> index.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactMapRangeIndex.java
>  ce1ea08 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
>  d5dd5a6 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/MapRangeIndexMaintenanceJUnitTest.java
>  9833e43 
> 
> Diff: https://reviews.apache.org/r/51734/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Review Request 52137: GEODE-1925 : Copy the resources directory inside build directory

[nabarun nag]

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

Review request for geode, Jason Huynh and Dan Smith.


Repository: geode


Description
---

* Tests use the resources folder for its execution, hence it needs to be in the 
build directory.
* This was initially handled by gradle, but caused issues when test catagory 
tags were changed.
* This action is now handled by the test code.


Diffs
-

  extensions/geode-modules-tomcat7/build.gradle 3c75e56 
  
extensions/geode-modules-tomcat7/src/main/java/org/apache/geode/modules/session/catalina/DeltaSession7.java
 c9be3fe 
  extensions/geode-modules-tomcat8/build.gradle dfa86cf 
  extensions/geode-modules/build.gradle 81a926c 
  
extensions/geode-modules/src/test/java/org/apache/geode/modules/session/EmbeddedTomcat.java
 1d97149 
  
extensions/geode-modules/src/test/java/org/apache/geode/modules/session/TestSessionsBase.java
 a680d9e 

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


Testing
---


Thanks,

nabarun nag

Re: Review Request 51735: GEODE-1840: Certain map queries combine OR predicates into an AND junction

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Sept. 8, 2016, 10:26 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51735/
> ---
> 
> (Updated Sept. 8, 2016, 10:26 p.m.)
> 
> 
> Review request for geode, Barry Oglesby and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> When deciding whether to combine the predicates into a common junction, the 
> type should be checked to make sure they are the same.  This will prevent OR 
> junctions from being added/converted to an AND junction and vice versa.  This 
> was only affecting certain query paths.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/AbstractGroupOrRangeJunction.java
>  a14dda8 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/CompactRangeIndexQueryDUnitTest.java
>  8b27309 
> 
> Diff: https://reviews.apache.org/r/51735/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: IntelliJ project dependencies

[Nabarun Nag]

+1 Same issue as  Bruce's 1st email with IntelliJ 2016.2.1
Upgraded to 2016.2.2 - same issue again.

MacOS 10.11.6

The dependencies break down when a new IntelliJ major version is released.
GEODE-1194 fixed by Jens was  for  the dependency issue in IntelliJ
2016.1.1.





On Tue, Aug 16, 2016 at 3:53 PM Bruce Schuchardt 
wrote:

> I'm not sure what I had this morning but I'm now using 2016.2.2
> community edition with the same JDK you're using.  Maybe it's a problem
> unique to MS-Windows.
>
>
> Le 8/16/2016 à 3:43 PM, Kirk Lund a écrit :
> > The project I'm using was created/imported today. My modules view for
> > geode-core shows the tools.jar in the list of the Project Settings
> > | Modules | Dependencies for geode-core:
> >
> > geode-core_jca
> > geode-core_legacyDUnit
> > geode-core_main
> > geode-core_test
> >
> > Here's my IntelliJ version and info (on Mac) according to the About:
> >
> > IntelliJ IDEA 2016.1.2
> > Build #IC-145.971, built on April 29, 2016
> > JRE: 1.8.0_76-release-b162 x86_64
> > JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
> >
> > My Project Settings | Modules | Dependencies also shows that I'm using
> > "jdk1.8.0_66" -- I'm not sure why that's different from the info in the
> > About window.
> >
> > -Kirk
> >
> >
> > On Tue, Aug 16, 2016 at 3:28 PM, Bruce Schuchardt <
> bschucha...@pivotal.io>
> > wrote:
> >
> >> After pulling down the latest patches to IntelliJ this worked for me as
> >> well, though it still doesn't configure geode-core to require tools.jar.
> >> Thanks Kirk
> >>
> >>
> >> Le 8/16/2016 à 12:21 PM, Kirk Lund a écrit :
> >>
> >>> All I know of is upgrading Gradle version to 2.14.1 on Aug 2.
> >>>
> >>> I just built a new IntelliJ project for Geode myself without any
> problems.
> >>> I don't use the "gradle idea" target (is that what you're using?). That
> >>> produces a project that doesn't work for me. Instead I create a new
> >>> "Project from Existing Sources" like this:
> >>>
> >>> 1) File | New | "Project from Existing Sources..."
> >>> 2) select your Geode checkout and hit OK
> >>> 3) select "Import project from external model", select Gradle and hit
> Next
> >>>
> >>> -Kirk
> >>>
> >>>
> >>> On Tue, Aug 16, 2016 at 10:37 AM, Bruce Schuchardt <
> >>> bschucha...@pivotal.io>
> >>> wrote:
> >>>
> >>> Has something changed in project dependencies recently?
>  I rebuilt my IntelliJ project last Friday and found that there were
>  missing dependencies that broke my build.  The modules geode-web_test,
>  geode-cq_test, geode-lucene_test, etc, did not have a dependency on
>  geode-core_test.  That gave IntelliJ all sorts of grief until I
> manually
>  added them.
> 
> 
> 
>
>

Re: Review Request 51044: GEODE-1737: gfsh query on region that does not exist may cause NPE

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On Aug. 12, 2016, 4:44 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51044/
> ---
> 
> (Updated Aug. 12, 2016, 4:44 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If a query on a region did not exist, a null is returned.  This causes an npe 
> that needs to be checked for.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  ae87b72 
> 
> Diff: https://reviews.apache.org/r/51044/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 51044: GEODE-1737: gfsh query on region that does not exist may cause NPE

[nabarun nag]

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




geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
 (line 1315)
<https://reviews.apache.org/r/51044/#comment211949>

Can it be put as an else condition here? (as we are already doing the check 
here)


- nabarun nag


On Aug. 12, 2016, 4:44 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51044/
> ---
> 
> (Updated Aug. 12, 2016, 4:44 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> If a query on a region did not exist, a null is returned.  This causes an npe 
> that needs to be checked for.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
>  ae87b72 
> 
> Diff: https://reviews.apache.org/r/51044/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 50615: GEODE-1676: Multiple Not Equals in query with Compact Range Index returns incorrect results

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On July 29, 2016, 9:16 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50615/
> ---
> 
> (Updated July 29, 2016, 9:16 p.m.)
> 
> 
> Review request for geode, anilkumar gingade and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The keysToRemove set was being removed from during iteration of the index.  
> This is as expected, however a copy of the keysToRemove should be made first 
> because the same set will be passed to the next bucket.  We would end up 
> removing from the original set and as we continued the query to the next 
> bucket, it would eventually be an empty set.
> 
> PdxString and Strings were not being properly compared in TypeUtils (which is 
> used by CompactRangeIndexes, among others)
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/index/MemoryIndexStore.java
>  83f8c02 
>   
> geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/types/TypeUtils.java
>  14c798f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/CompactRangeIndexQueryDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/types/TypeUtilTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/50615/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Review Request 50811: GEODE-1241: Fixing the misspelt words in the geode-wan

[nabarun nag]

/cache/wan/offheap/ParallelWANPropogationConcurrentOpsOffHeapDUnitTest.java
 aa74fa8 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/offheap/ParallelWANPropogationOffHeapDUnitTest.java
 4a77012 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/offheap/SerialWANPropagationOffHeapDUnitTest.java
 PRE-CREATION 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/offheap/SerialWANPropagation_PartitionedRegionOffHeapDUnitTest.java
 PRE-CREATION 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/offheap/SerialWANPropogationOffHeapDUnitTest.java
 625d028 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/offheap/SerialWANPropogation_PartitionedRegionOffHeapDUnitTest.java
 d755404 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelGatewaySenderQueueOverflowDUnitTest.java
 44308f8 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANConflationDUnitTest.java
 d73ac17 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANPersistenceEnabledGatewaySenderDUnitTest.java
 be3c42d 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANPropagationConcurrentOpsDUnitTest.java
 f55a1eb 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANPropagationDUnitTest.java
 804da23 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/parallel/ParallelWANStatsDUnitTest.java
 16a5d92 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderDistributedDeadlockDUnitTest.java
 2595275 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderEventListenerDUnitTest.java
 cb55a2a 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderOperationsDUnitTest.java
 2e796e7 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialGatewaySenderQueueDUnitTest.java
 7776402 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPersistenceEnabledGatewaySenderDUnitTest.java
 bd4555f 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropagationDUnitTest.java
 PRE-CREATION 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropagationLoopBackDUnitTest.java
 4b53626 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropagation_PartitionedRegionDUnitTest.java
 PRE-CREATION 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropagationsFeatureDUnitTest.java
 PRE-CREATION 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropogationDUnitTest.java
 5a32884 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropogation_PartitionedRegionDUnitTest.java
 c51c992 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANPropogationsFeatureDUnitTest.java
 f67639b 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
 8d6efe1 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/wancommand/WANCommandTestBase.java
 ec38b31 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/wancommand/WanCommandListDUnitTest.java
 1a145cb 
  
geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/wancommand/WanCommandStatusDUnitTest.java
 362df80 
  
geode-wan/src/test/java/com/gemstone/gemfire/management/WANManagementDUnitTest.java
 4d17d9b 
  
geode-wan/src/test/java/com/gemstone/gemfire/management/internal/configuration/ClusterConfigurationDUnitTest.java
 692f92f 
  
geode-wan/src/test/java/com/gemstone/gemfire/management/internal/pulse/TestRemoteClusterDUnitTest.java
 22294ee 

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


Testing
---

precheckin tag nnag1241


Thanks,

nabarun nag

Re: Flaky tests failing with BindException

[Nabarun Nag]

+1 for the retry.

In my opinion, maintaining available port lists maybe hard as we move
towards running test modules in parallel. Also maybe some non-geode entity
may come up and pick up a port hence we will need to constantly
refresh/update the list before/after each test run. (1 ports needs to
be checked as per geode getRandomWildcardBindPortNumber)


Also for GEODE-1600 fix, DUnitLauncher now passes 0 as the port number
while creating a locator. The system assigns it an available port number
while staring the server rather than getting a random available port number
first then asking things to be started on that port. (race conditions
ensues )

On Fri, Jul 29, 2016 at 2:36 PM William Markito  wrote:

> Why not create a JUnit rule that returns available ports and keep track of
> ports being used ?
>
> I've cloned this gist from somewhere (don't remember now) but I've planning
> to send it for discussion...
>
> https://gist.github.com/markito/b5be3fc570c7c7c84e6d09e064a6e898
>
> Still talking about rules, I've played a bit with the TemporaryFolder rule
> and that's very useful as well, specially to clean up after test runs and
> to avoid conflicts.
>
> http://junit.org/junit4/javadoc/4.12/org/junit/rules/TemporaryFolder.html
>
> Just my 2c
>
> On Fri, Jul 29, 2016 at 1:54 PM, Hitesh Khamesra <
> hitesh...@yahoo.com.invalid> wrote:
>
> > Is there any possibility of running multiple test same time on that
> > machine?
> >
> > -Hitesh
> >
> >
> >   From: Kirk Lund 
> >  To: geode 
> >  Sent: Friday, July 29, 2016 1:21 PM
> >  Subject: Flaky tests failing with BindException
> >
> > Many of our flaky tests are flaky because they use AvailablePort or
> > AvailablePortHelper to find randomly available ports. They then later
> fail
> > with a BindException because the port is already in use by the time the
> > test uses it.
> >
> > Here's a proposal for a temporary fix:
> >
> > The module geode-junit contains a JUnit 4 rule called RetryRule. We could
> > modify RetryRule to only retry if a BindException (or configurable
> > exception/s) is detected. This rule would then be dropped into every test
> > that uses AvailablePort or AvailablePortHelper. Then if the test fails
> with
> > a BindException, it would automatically retry (once or twice or whatever
> we
> > decide to configure RetryRule with). If the test fails without any
> detected
> > BindException, then it would just fail without retrying.
> >
> > Opinions on this?
> >
> > Thanks,
> > Kirk
> >
> >
> >
> >
>
>
>
> --
>
> ~/William
>

Review Request 50304: GEODE-1674: Using a immuatable object to pass the HashIndexSet and its mask

[nabarun nag]

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

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


Repository: geode


Description
---

* Immutable ojects pairs the mask and set together
* There is no race condition in which the mask differs from the set leading to 
any ArrayOutOfBoundsException.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/cache/query/internal/index/HashIndexSet.java
 5ed724b 
  
geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/index/HashIndexJUnitTest.java
 e2a8643 
  
geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/index/HashIndexSetJUnitTest.java
 7f96fde 

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


Testing
---

Precheck-in with no failures.


Thanks,

nabarun nag

Re: Missing Sign Off on Board Report

[Nabarun Nag]

As per the incubator wiki,

Tue July 12

Mentor signoff due by end of day


Please do let us know if any modifications are required  in the report.

Regards
Nabarun Nag

On Tue, Jul 12, 2016 at 11:00 AM Kirk Lund <kl...@pivotal.io> wrote:

> Please let us know if we skipped anything on our end for getting this
> reported completed.
>
> Thank you,
> Kirk
>
>
> On Tue, Jul 12, 2016 at 10:40 AM, John D. Ament <johndam...@apache.org>
> wrote:
>
> > Geode Podling,
> >
> > Your report is missing sign off from your mentors.  Please try to get it
> > ASAP.
> >
> > John
> >
>

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

[nabarun nag]

> On June 30, 2016, 11:14 p.m., nabarun nag wrote:
> > geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java,
> >  line 303
> > <https://reviews.apache.org/r/49102/diff/1/?file=1427588#file1427588line303>
> >
> > Hi Jason, 
> > While debugging this ticket we found out that the boolean 
> > startAckReaderThread is completely ignore by the method getConnection. 
> > Should we make use of it in line 329 
> > if (this.ackReaderThread == null || !this.ackReaderThread.isRunning())
> > 
> > Or refactor the method signature.

Sorry, i dont know what the protocol is for "open" issue. Checked it by mistake 
and I can't edit it


- nabarun


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


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 49102: WAN Ack reader thread needs to be shut down before sending a close connection

[nabarun nag]

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




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

Hi Jason, 
While debugging this ticket we found out that the boolean 
startAckReaderThread is completely ignore by the method getConnection. 
Should we make use of it in line 329 
if (this.ackReaderThread == null || !this.ackReaderThread.isRunning())

Or refactor the method signature.


- nabarun nag


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 49471: GEODE-1374: Flaky tests will now have junit xml recorded into seperate directory

[nabarun nag]

> On June 30, 2016, 11:06 p.m., nabarun nag wrote:
> > Ship It!

Change made in Jenkins Precheckin to pick up the new folder.


- nabarun


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


On June 30, 2016, 8:50 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49471/
> ---
> 
> (Updated June 30, 2016, 8:50 p.m.)
> 
> 
> Review request for geode, Kirk Lund, nabarun nag, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Flaky xml results were overwriting non flaky test results that had the same 
> FQCN
> We now can write these xml results into their own directory and have jenkins 
> crawl this new folder as well
> 
> 
> Diffs
> -
> 
>   gradle/test.gradle eb10cad 
> 
> Diff: https://reviews.apache.org/r/49471/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 49471: GEODE-1374: Flaky tests will now have junit xml recorded into seperate directory

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On June 30, 2016, 8:50 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/49471/
> ---
> 
> (Updated June 30, 2016, 8:50 p.m.)
> 
> 
> Review request for geode, Kirk Lund, nabarun nag, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Flaky xml results were overwriting non flaky test results that had the same 
> FQCN
> We now can write these xml results into their own directory and have jenkins 
> crawl this new folder as well
> 
> 
> Diffs
> -
> 
>   gradle/test.gradle eb10cad 
> 
> Diff: https://reviews.apache.org/r/49471/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: [INFO REQUEST] Uploading the podling report

[Nabarun Nag]

Thanks Swapnil. Email sent.

On Thu, Jun 30, 2016 at 3:51 PM Swapnil Bawaskar <sbawas...@pivotal.io>
wrote:

> Send an email to gene...@incubator.apache.org asking for permissions to
> the
> wiki for uploading the podling report.
>
> On Thu, Jun 30, 2016 at 3:19 PM, Nabarun Nag <n...@pivotal.io> wrote:
>
> > Hi,
> >
> > Thank you all for the reviews.
> >
> > Can someone please tell me the steps to append the podling report to
> > http://wiki.apache.org/incubator/July2016.
> >
> >
> > Regards
> > Nabarun Nag
> >
>

[INFO REQUEST] Uploading the podling report

[Nabarun Nag]

Hi,

Thank you all for the reviews.

Can someone please tell me the steps to append the podling report to
http://wiki.apache.org/incubator/July2016.


Regards
Nabarun Nag

Re: Podling Report Reminder - July 2016

[Nabarun Nag]

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 <n...@pivotal.io> 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 <dsm...@pivotal.io> 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, <johndam...@apache.org> 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
>> > submission (Wed, July 06).
>> >
>> > Please submit your report with sufficient time to allow the Incubator
>> > PMC, and subsequently board members to review and digest. Again, the
>> > very latest you should submit your report is 2 weeks prior to the board
>> > meeting.
>> >
>> > Thanks,
>> >
>> > The Apache Incubator PMC
>> >
>> > Submitting your Report
>> >
>> > --
>> >
>> > Your report should contain the following:
>> >
>> > *   Your project name
>> > *   A brief description of your project, which assumes no knowledge of
>> > the project or necessarily of its field
>> > *   A list of the three most important issues to address in the move
>> >

Re: Podling Report Reminder - July 2016

[Nabarun Nag]

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
> > submission (Wed, July 06).
> >
> > Please submit your report with sufficient time to allow the Incubator
> > PMC, and subsequently board members to review and digest. Again, the
> > very latest you should submit your report is 2 weeks prior to the board
> > meeting.
> >
> > Thanks,
> >
> > The Apache Incubator PMC
> >
> > Submitting your Report
> >
> > --
> >
> > Your report should contain the following:
> >
> > *   Your project name
> > *   A brief description of your project, which assumes no knowledge of
> > the project or necessarily of its field
> > *   A list of the three most important issues to address in the move
> > towards graduation.
> > *   Any issues that the Incubator PMC or ASF Board might wish/need to be
> > aware of
> > *   How has the community developed since the last report
> > *   How has the project developed since the last report.
> >
> > This should be appended to the Incubator Wiki page at:
> >
> > http://wiki.apache.org/incubator/July2016
> >
> > Note: This is manually populated. You may need to wait a little before
> > this page is created from a template.
> >
> > Mentors
> > ---
> >
> > Mentors should review reports for their project(s) and sign them off on
> > the Incubator wiki page. Signing off reports shows that you are
> > following the project - projects that are not signed may raise alarms
> > for the Incubator PMC.
> >
> > Incubator PMC
> >
>

Re: Review Request 48661: GEODE-1543: Changed the log level from error to warn

[nabarun nag]

> On June 13, 2016, 9:33 p.m., Dan Smith wrote:
> > If this is expected behavior, I think this message should be info level or 
> > lower. warning still indicates that something is going wrong.
> 
> Jason Huynh wrote:
> I agree, probably should be info for this.
> 
> nabarun nag wrote:
> I was wondering that the catch block is for general exception ( Exception 
> ex ) which might occur for multiple reaons which may not have been an 
> expected scenario. (The try block had multiple lines of code and i thought 
> that an exception may occur at any point).
> 
> I think that we should have a separate catch block for the expected 
> scenario with the info level message and leave the general exception catch 
> block with the error level log message.
> 
> I might be wrong about this :(
> 
> Dan Smith wrote:
> That seems like a good idea.

After further analysis, I found that there are two checked exceptions which 
were caught by the previous generic catch block. RegionNotFound Exception and 
IndexExistsException. RegionNotFoundException will now be treated as an 
InternalGemFireError and rethrown. However, the IndexExistsException will 
require more detailed analysis. TBD


- nabarun


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


On June 13, 2016, 7:33 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48661/
> ---
> 
> (Updated June 13, 2016, 7:33 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, Dan Smith, and 
> xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When multiple peers join the cluster conncurrently, only the first one that 
> joins will distribute the index creation and other will try to create the 
> index locally because of the distributed message and then log an error 
> afterwards.
> * This is an expected behaviour and hence should not be logged as error but 
> rather as a warning.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
> 8b9664f 
> 
> Diff: https://reviews.apache.org/r/48661/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Re: Review Request 48661: GEODE-1543: Changed the log level from error to warn

[nabarun nag]

> On June 13, 2016, 9:33 p.m., Dan Smith wrote:
> > If this is expected behavior, I think this message should be info level or 
> > lower. warning still indicates that something is going wrong.
> 
> Jason Huynh wrote:
> I agree, probably should be info for this.

I was wondering that the catch block is for general exception ( Exception ex ) 
which might occur for multiple reaons which may not have been an expected 
scenario. (The try block had multiple lines of code and i thought that an 
exception may occur at any point).

I think that we should have a separate catch block for the expected scenario 
with the info level message and leave the general exception catch block with 
the error level log message.

I might be wrong about this :(


- nabarun


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


On June 13, 2016, 7:33 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/48661/
> ---
> 
> (Updated June 13, 2016, 7:33 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Jason Huynh, Dan Smith, and 
> xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * When multiple peers join the cluster conncurrently, only the first one that 
> joins will distribute the index creation and other will try to create the 
> index locally because of the distributed message and then log an error 
> afterwards.
> * This is an expected behaviour and hence should not be logged as error but 
> rather as a warning.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
> 8b9664f 
> 
> Diff: https://reviews.apache.org/r/48661/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> nabarun nag
> 
>

Review Request 48661: GEODE-1543: Changed the log level from error to warn

[nabarun nag]

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

Review request for geode, anilkumar gingade, Jason Huynh, Dan Smith, and 
xiaojian zhou.


Repository: geode


Description
---

* When multiple peers join the cluster conncurrently, only the first one that 
joins will distribute the index creation and other will try to create the index 
locally because of the distributed message and then log an error afterwards.
* This is an expected behaviour and hence should not be logged as error but 
rather as a warning.


Diffs
-

  geode-core/src/main/java/com/gemstone/gemfire/internal/cache/LocalRegion.java 
8b9664f 

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


Testing
---


Thanks,

nabarun nag

Re: Review Request 46914: GEODE-11: Fixing a class cast exception when LuceneFunction has an error

[nabarun nag]

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



Dan, these comments are just for my understanding[no actual issues with the 
code.]


geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/distributed/LuceneFunction.java
 (line 85)
<https://reviews.apache.org/r/46914/#comment195394>

Dan just for me to learn, why is a FunctionException being thrown rather 
than a QueryException



geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/distributed/LuceneFunction.java
 (line 111)
<https://reviews.apache.org/r/46914/#comment195402>

Same here why rather doing an isInstanceOf call and throwing the 
corresponding exception


- nabarun nag


On May 2, 2016, 10:32 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46914/
> ---
> 
> (Updated May 2, 2016, 10:32 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> LuceneFunction was using sendException to return exceptions to caller.
> But the behavior of sendException is actually to pass the exception to
> the addResult method, which is not what we want in this case.
> 
> Adding an integration test of the same. Changing LuceneFunctionJUnitTest
> to use mockito and changing the excepectations of what LuceneFunction
> will do after an exception.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/distributed/LuceneFunction.java
>  199b698c295e901cbd5450c263a6301f6db8970c 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/distributed/TopEntriesCollectorManager.java
>  b19e1041d830363383c1bfa00bed6f7ac8a4b057 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesIntegrationJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/distributed/LuceneFunctionJUnitTest.java
>  750ec0f6ba2a07e90567693c24b06647f8ee 
> 
> Diff: https://reviews.apache.org/r/46914/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 45938: GEODE-1062: Undoing reduction in wait time

[Nabarun Nag]

As per Jason's advice I will open a new ticket for rewriting the test case
design as tests are not suppose to wait for 4 min.
Also, while running all the WAN tests on IntelliJ I was able to find more
tests with timing issue which Jason and me solved earlier. (Running two
IntelliJ instances simultaneously )
Will create the ticket and push in the changes.
On Fri, Apr 8, 2016 at 1:45 PM Barry Oglesby <bogle...@pivotal.io> wrote:

> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45938/
>
> Ship it!
>
> Ship It!
>
>
> - Barry Oglesby
>
> On April 8th, 2016, 8:26 p.m. UTC, Jason Huynh wrote:
> Review request for geode, anilkumar gingade, Barry Oglesby, nabarun nag,
> Dan Smith, and xiaojian zhou.
> By Jason Huynh.
>
> *Updated April 8, 2016, 8:26 p.m.*
> *Repository: * geode
> Description
>
> Some tests with overflow require the full 24 millisecond timeout...
>
> Diffs
>
>- 
> geode-wan/src/test/java/com/gemstone/gemfire/internal/cache/wan/WANTestBase.java
>(130f960)
>
> View Diff <https://reviews.apache.org/r/45938/diff/>
>

Re: Review Request 45497: GEODE-1079: Removing unused dist.gemstone.com repository

[nabarun nag]

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


Ship it!




Ship It!

- nabarun nag


On March 30, 2016, 5:34 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45497/
> ---
> 
> (Updated March 30, 2016, 5:34 p.m.)
> 
> 
> Review request for geode and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Removing dist.gemstone.com from the list of repositories in
> build.gradle, because it is not used.
> 
> 
> Diffs
> -
> 
>   build.gradle 200dd8aadc787ef87577b50d06aae30f8949f3ef 
> 
> Diff: https://reviews.apache.org/r/45497/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>