Re: [VIDEO] Geode Clubhouse Replay Posted : Events & Continuous Query

[Gregory Chase]

Greetings Geode Community,
Whether you missed yesterday's Geode Clubhouse, or just want to watch the
discussion again, we've posted the video replay here:
https://youtu.be/ktsmi9E28zM.

This was a great presentation, demo, and long running discussion about the
eventing and continuous query features of Apache Geode.  We also took
several beginner and advanced questions on the topic.

Here's your detailed guide:

1:10 Mike Stolz presenting on events & continuous query features on Geode


7:10 Question: How is a good way to connect message queues to Geode?


8:40 Question: How do you create custom partitioning?


10:04 Question: How does one control continuous query buffer sizes?


12:15 Demo by Luke Shannon continuous query in Spring Boot, and event
handling in a Spring Data GemFire application


28:50 Question: What failure scenarios are handled for event delivery and
processing? 

33:38 Question: Can CQ be handled on the cluster side?


35:45 Question: What are the trade-offs between CQ and event registration?


41:50 Question: How might Geode work with or as a distributed queue?


47:08 Question: What about using Geode with Scala?


49:30 Question: Will CQ send notifications for when values pass out of
range of interest? 

On Thu, Jul 28, 2016 at 8:14 AM, Gregory Chase  wrote:

> Here's the announcement all you procrastinators have been waiting for...
>
> The next Geode Clubhouse starts in 45 minutes.
>
> Join the meeting at this link
> .
>
> See you soon!
>
> -Greg
>
> On Wed, Jul 27, 2016 at 12:55 PM, Gregory Chase  wrote:
>
>> Dear Geode Community,
>> This is a reminder about tomorrow's virtual Geode Clubhouse Meeting.
>> Please join us tomorrow at 9AM.
>>
>> Join the meeting at this link
>> .  You can add a
>> reminder to your calendar with this link
>> 
>> .
>>
>> Regards,
>>
>> -Greg
>>
>> On Fri, Jul 22, 2016 at 1:31 PM, Gregory Chase  wrote:
>>
>>> Dear Apache Geode (incubating) community,
>>> Don't miss the next Geode Clubhouse community meeting, next Thursday,
>>> July 28 at 9AM Pacific.
>>>
>>> Join the meeting at this link
>>> .  You can add a
>>> reminder to your calendar with this link
>>> 
>>> .
>>>
>>> Luke Shannon and Mike Stolz will discuss the event-handling and queuing
>>> capabilities of Apache Geode, as well as the recently added Continuous
>>> Query feature.
>>>
>>> We'll also take questions, and show a demo of these capabilities in the
>>> context of a Geode-powered application.
>>>
>>> See you next Thursday!
>>>
>>> -Greg
>>>
>>> --
>>> Greg Chase
>>>
>>> Global Head, Big Data Communities
>>> http://www.pivotal.io/big-data
>>>
>>> Pivotal Software
>>> http://www.pivotal.io/
>>>
>>> 650-215-0477
>>> @GregChase
>>> Blog: http://geekmarketing.biz/
>>>
>>>
>>
>>
>> --
>> Greg Chase
>>
>> Global Head, Big Data Communities
>> http://www.pivotal.io/big-data
>>
>> Pivotal Software
>> http://www.pivotal.io/
>>
>> 650-215-0477
>> @GregChase
>> Blog: http://geekmarketing.biz/
>>
>>
>
>
> --
> Greg Chase
>
> Global Head, Big Data Communities
> http://www.pivotal.io/big-data
>
> Pivotal Software
> http://www.pivotal.io/
>
> 650-215-0477
> @GregChase
> Blog: http://geekmarketing.biz/
>
>


-- 
Greg Chase

Global Head, Big Data Communities
http://www.pivotal.io/big-data

Pivotal Software
http://www.pivotal.io/

650-215-0477
@GregChase
Blog: http://geekmarketing.biz/

[GitHub] incubator-geode pull request #220: GEODE-11: Lucene gfsh exceptions and retu...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-geode/pull/220


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

[GitHub] incubator-geode issue #220: GEODE-11: Lucene gfsh exceptions and return keys...

[gesterzhou]

Github user gesterzhou commented on the issue:

https://github.com/apache/incubator-geode/pull/220
  
+1


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

[GitHub] incubator-geode pull request #220: GEODE-11: Lucene gfsh exceptions and retu...

[aparnard]

GitHub user aparnard opened a pull request:

https://github.com/apache/incubator-geode/pull/220

GEODE-11: Lucene gfsh exceptions and return keys of search results

- Added exception handling to lucene search and describe gfsh commands to 
handle region not found, index not found and invalid query string exceptions.

- Added an option to the lucene search command to return only keys of the 
search results. Added dunit and junit tests to verify

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

$ git pull https://github.com/aparnard/incubator-geode 
feature/GEODE-11-Lucene-gfsh-exceptions

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

https://github.com/apache/incubator-geode/pull/220.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #220


commit f522b036131b37137f9a94a74f9c5753a19db09e
Author: Aparna Dharmakkan 
Date:   2016-07-29T21:48:19Z

GEODE-11: Added exception handling to lucene gfsh commands

Added exception handling to lucene search and describe gfsh commands to 
handle region not found, index not found and invalid query string exceptions.

commit ad776cc01c968336dc88abee998a957a9b9a728a
Author: Aparna Dharmakkan 
Date:   2016-07-29T23:15:09Z

GEODE-11: gfsh lucene search command returns only keys

Added an option to the lucene search command to return only keys of the 
search results. Added dunit and junit tests to verify

Signed-off-by: Gester Zhou 




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

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

[Spring CI]

---
Spring Data GemFire > Nightly-ApacheGeode > #385 was successful.
---
Scheduled
1425 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Flaky tests failing with BindException

[Bruce Schuchardt]

I'm making another change that will help.

One of the problems with these tests is that they will choose a random 
port for a Cache Server or some other component and only use the port 
after opening a cache.  Doing that allows the communications/membership 
component to grab two ports. AvailablePort restricts the ports it hands 
out to the range [2, 3], so if we restrict the 
communications/membership component to use ports outside of that range 
it will help avoid collisions.


Le 7/29/2016 à 3:23 PM, Nabarun Nag a écrit :

+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

Re: Flaky tests failing with BindException

[Jens Deppe]

We're pretty close to being able to run parallel tests in docker. With
that, Flakys could be run individually per container which should solve the
bind issues.

--Jens

On Fri, Jul 29, 2016 at 2:35 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
>

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
>

Re: Review Request 50420: there is a race that cache is still initializing, some components are not ready

[xiaojian zhou]

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

(Updated July 29, 2016, 10:13 p.m.)


Review request for geode, anilkumar gingade and Dan Smith.


Changes
---

In this test, the accessor is a datastore, it also has a sender. So it also 
should be suspended. Otherwise the data will be distributed to the index 
regions from the accessor's index regions.


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


Repository: geode


Description
---

Need to add Awaitility.waitAtMost


Diffs (updated)
-

  
geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesPeerPRRedundancyDUnitTest.java
 dc86a7c 

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


Testing
---


Thanks,

xiaojian zhou

Re: Flaky tests failing with BindException

[William Markito]

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 50615: GEODE-1676: Multiple Not Equals in query with Compact Range Index returns incorrect results

[Jason Huynh]

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

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

Re: Flaky tests failing with BindException

[Hitesh Khamesra]

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


   

Re: Flaky tests failing with BindException

[Kenneth Howe]

Sounds like it would improve the results, but not necessarily fix, 
BindException @Flaky test failures. Even after n number of retries we’d still 
not be sure of finding the requested port available. Has any testing been done 
to find a point of diminishing returns on increasing the retry count? 

Ken

> On Jul 29, 2016, at 1:21 PM, Kirk Lund  wrote:
> 
> 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

Re: geode-core distributedTest statistics

[Kirk Lund]

We could probably make some changes to testAllOpsWithFailover() now to make
it run for a much shorter time. Do we want to file on Jira ticket to
shorten the run times of tests? Do we need sub-task tickets for each test
or for groups of tests?

-Kirk


On Fri, Jul 29, 2016 at 10:17 AM, Jinmei Liao  wrote:

> We will get rid of ClientAuthorizationDUnitTest altogether once we remove
> the old security.
>
> On Fri, Jul 29, 2016 at 10:09 AM, Bruce Schuchardt  >
> wrote:
>
> > Here are some stats on the run-time of our geode-core distributedTests.
> >
> > There are 7431 geode-core distributedTests.  On my last run these took
> 280
> > minutes to execute.
> >
> > 5% of the tests run for over 10 seconds and are taking 50% of the time
> > (140 minutes).
> >
> > 2.5% run for over 20 seconds and are taking 33% of the time (92 minutes).
> >
> > 0.8% run for over 30 seconds and are taking 20% of the time (55 minutes).
> >
> > ClientAuthorizationDUnitTest.testAllOpsWithFailover() runs for 7 minutes
> > and wins the prize for longest-running test.  The runner-up trails far
> > behind at 2.1 minutes.
> >
>
>
>
> --
> Cheers
>
> Jinmei
>

Flaky tests failing with BindException

[Kirk Lund]

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

Re: Review Request 50587: Merge from 82 and couple of other perf related improvements

[Bruce Schuchardt]

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




geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java 
(line 425)


This "if" needs braces



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HARegionQueue.java
 (line 1604)


remove this TODO



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HARegionQueue.java
 (line 3722)


I wish this code wasn't duplicated in AbstractRegionMap.



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/LockObject.java
 (line 23)


Since this is never decremented it could be a boolean instead of an int.  
It looks like you started coding this & thought you would decrement the 
variable but then decided you didn't need to.



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Message.java
 (line 341)


I know you're just merging stuff that other people did but this code really 
should be in serializeAndAddPart instead of addObjPart.



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Part.java
 (line 190)


Remove customer name from this comment.  I think they were all changed to 
"performance"



geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Part.java
 (line 191)


We should change this to limit it to 16-bit integers.  I don't see any uses 
of it that would cause memory bloat in the current code base but that could 
change in the future.


- Bruce Schuchardt


On July 28, 2016, 11:43 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50587/
> ---
> 
> (Updated July 28, 2016, 11:43 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, Bruce Schuchardt, Jason Huynh, and 
> Jacob Barrett.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This includes merge from 82. Please check your chengaes with 82
> 
> 
> jason 79be29188b440e217cda50e41af853f882dd9193
> jason 49e6458fcc2aa294fc5dfd41ba47bddc92f29dfe
> jason 30ba06dbc5ee06dab7b0ff7b7275619612b7a868
> jacob 1544bda2c722bddf94db6f2e807b302f9b5df303
> Jacob 97cd29a821b770a54412c4abf20f5df0398e9405
> barry 37a942b9ab33e301f3bd41270a63ad0433f184bd
> barry 3210ed80258a6518f8b92ae9adfd96e18db1f218
> barry 486a653d037ed3f13c7061abe887d6ab306261d4
> barry 35a6c8b6236ef329fe5ace121c657b529725ec32
> barry 09f9b953b07b26bc3a19cc00c22f8ed047f6f6cf
> barry 49fc39dc7224fe42f73b6363de66b6f8f6ed7be6
> Amogh changes 18dd055dc75f94c460fba81d7dfdc2617fafb0a5
> b3322a097cdf0d9ecaf94c600b61c7d62d772cea
> 
> Other improvement:We take lock on key while doing op on BucketRegion. 
> In that case wenotify to other thread only when there is thread waiting for 
> it.
> Modified condition to log message.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/AbstractRegionMap.java
>  f3cb3d6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java
>  abe38b6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedCacheOperation.java
>  f51717d 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/FilterRoutingInfo.java
>  7f5b587 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HAContainerMap.java
>  084140f 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HAContainerRegion.java
>  eeefaee 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HAContainerWrapper.java
>  b0f3e45 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HARegionQueue.java
>  85b50a1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/partitioned/LockObject.java
>  612b71a 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientNotifier.java
>  d351569 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/ClientUpdateMessageImpl.java
>  0fb915e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Message.java
>  459cf5f6 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/Part.java
>  1c3819e 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/wan/parallel/ConcurrentParallelGatewaySenderEventProcessor.java
>  8b6a700 
>   
> 

Re: geode-core distributedTest statistics

[Jinmei Liao]

We will get rid of ClientAuthorizationDUnitTest altogether once we remove
the old security.

On Fri, Jul 29, 2016 at 10:09 AM, Bruce Schuchardt 
wrote:

> Here are some stats on the run-time of our geode-core distributedTests.
>
> There are 7431 geode-core distributedTests.  On my last run these took 280
> minutes to execute.
>
> 5% of the tests run for over 10 seconds and are taking 50% of the time
> (140 minutes).
>
> 2.5% run for over 20 seconds and are taking 33% of the time (92 minutes).
>
> 0.8% run for over 30 seconds and are taking 20% of the time (55 minutes).
>
> ClientAuthorizationDUnitTest.testAllOpsWithFailover() runs for 7 minutes
> and wins the prize for longest-running test.  The runner-up trails far
> behind at 2.1 minutes.
>



-- 
Cheers

Jinmei

Review Request 50608: GEODE-1569: post process for serialized domain objects

[Jinmei Liao]

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

Review request for geode, Grace Meilen, Kevin Duling, and Kirk Lund.


Repository: geode


Description
---

* for client/server retreival, post process the value before it was put into 
the message
* for gfsh commands, post process the value before it was put into the command 
result json
* tests added to ensure correct domain object or pdx instances are passed to 
the post processor.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/BaseCommandQuery.java
 0e32fb8481410f5d453dea036bfd587c7bf80463 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/CacheClientProxy.java
 46737b7d7384f1a3468d163cd2fde35c670f785a 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/Get70.java
 f6e17ae1dd50431eb10ef68673ae51d1557f1271 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/GetAll.java
 5ae5d126f0706842e58dbb1898eb364ed650e813 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/GetAll651.java
 5b278e3f4e5e2425c6cdbb01d2957b2189c2550a 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/tier/sockets/command/GetAll70.java
 c1ab7a9fe932cb7d88e1affa1490e3366b2f92d1 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/security/GeodeSecurityUtil.java
 3694d2ce9d9a4e3eae5e3b8801c8a31b07d72ba0 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/commands/DataCommands.java
 bdbaa150bfcfd196fca7ec227c7a644c282d751d 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/DataCommandFunction.java
 ed119a594c02d0906360bfc25c6a83503221f223 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/json/GfJsonObject.java
 1849066f4484be80ae0fa7b224f610199e90ce67 
  
geode-core/src/test/java/com/gemstone/gemfire/security/AbstractIntegratedClientAuthDistributedTest.java
 feda4b4a0c52387e6f17d45925fefd4ddb9e0af3 
  
geode-core/src/test/java/com/gemstone/gemfire/security/IntegratedSecurityPostProcessorDUnitTest.java
 0568659661dd1d7f4459f148249b28e195959b83 
  
geode-cq/src/test/java/com/gemstone/gemfire/security/IntegratedClientQueryAuthDistributedTest.java
 d9b69b79b6e99db39a5fe6a001bddae4ce60e168 
  
geode-cq/src/test/java/com/gemstone/gemfire/security/PDXPostProcessorDUnitTest.java
 PRE-CREATION 
  geode-json/src/main/java/org/json/JSONObject.java 
24f5cc7fe7d8db5e75c6142a64a4ceeea26f2008 

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


Testing
---

PDXPostProcessorDUnitTest

precheckin running


Thanks,

Jinmei Liao

geode-core distributedTest statistics

[Bruce Schuchardt]

Here are some stats on the run-time of our geode-core distributedTests.

There are 7431 geode-core distributedTests.  On my last run these took 
280 minutes to execute.


5% of the tests run for over 10 seconds and are taking 50% of the time 
(140 minutes).


2.5% run for over 20 seconds and are taking 33% of the time (92 minutes).

0.8% run for over 30 seconds and are taking 20% of the time (55 minutes).

ClientAuthorizationDUnitTest.testAllOpsWithFailover() runs for 7 minutes 
and wins the prize for longest-running test.  The runner-up trails far 
behind at 2.1 minutes.
 10034 ms 
com.gemstone.gemfire.internal.cache.wan.asyncqueue.AsyncEventListenerOffHeapDUnitTest
 testParallelAsyncEventQueueWithConflationEnabled
 10214 ms com.gemstone.gemfire.management.LocatorManagementDUnitTest 
testWillingManagersWithPortZero
 10321 ms com.gemstone.gemfire.internal.cache.IncrementalBackupDUnitTest 
testIncompleteInBaseline
 10362 ms com.gemstone.gemfire.cache30.SearchAndLoadDUnitTest testConcurrentLoad
 10444 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.DurableClientBug39997DUnitTest 
testNoServerAvailableOnStartup
 10460 ms com.gemstone.gemfire.management.internal.security.MultiUserDUnitTest 
testMultiUser
 10484 ms 
com.gemstone.gemfire.cache.query.internal.index.ConcurrentIndexOperationsOnOverflowRegionDUnitTest
 testAsyncIndexInitDuringEntryDestroyAndQueryOnPR
 10494 ms 
com.gemstone.gemfire.cache.query.internal.index.ConcurrentIndexOperationsOnOverflowRegionDUnitTest
 testAsyncIndexInitDuringEntryDestroyAndQueryOnPersistentRR
 10499 ms 
com.gemstone.gemfire.cache.query.internal.index.ConcurrentIndexOperationsOnOverflowRegionDUnitTest
 testAsyncIndexInitDuringEntryDestroyAndQueryOnRR
 10507 ms com.gemstone.gemfire.cache.query.dunit.QueryUsingPoolDUnitTest 
testClientServerCompiledQueryTimeBasedCleanup
 10639 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InterestListDUnitTest 
testInterestListRegistration_ALL_KEYS
 10643 ms com.gemstone.gemfire.pdx.PdxTypeExportDUnitTest testPeer
 10663 ms com.gemstone.gemfire.distributed.LocatorDUnitTest 
testLeadFailureAndCoordShutdown
 10667 ms 
com.gemstone.gemfire.cache.query.internal.index.ConcurrentIndexOperationsOnOverflowRegionDUnitTest
 testAsyncIndexInitDuringEntryDestroyAndQueryOnPersistentPR
 10671 ms 
com.gemstone.gemfire.internal.cache.partitioned.StreamingPartitionOperationManyDUnitTest
 testStreamingManyProvidersNoExceptions
 10672 ms com.gemstone.gemfire.internal.cache.PartitionedRegionQueryDUnitTest 
testPartitionRegionDebugMessageQueryTraceOnRemoteServerOnly
 10681 ms com.gemstone.gemfire.cache30.ClientMembershipSelectorDUnitTest 
testClientMembershipEventsInClient
 10724 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InstantiatorPropagationDUnitTest
 testInstantiatorsWith2ClientsN2Servers
 10747 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.CacheServerTransactionsDUnitTest
 testInvalidatesOneServerToClientTransactionsPropagation
 10785 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.CacheServerTransactionsSelectorDUnitTest
 testInvalidatesOneServerToClientTransactionsPropagation
 10787 ms 
com.gemstone.gemfire.cache.client.internal.LocatorLoadBalancingDUnitTest 
testLoadMessaging
 10789 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.CacheServerTransactionsDUnitTest
 testDestroysOneServerToClientTransactionsPropagation
 10816 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.CacheServerTransactionsSelectorDUnitTest
 testDestroysOneServerToClientTransactionsPropagation
 10820 ms 
com.gemstone.gemfire.distributed.internal.DistributionManagerDUnitTest 
testKickOutSickMember
 10942 ms 
com.gemstone.gemfire.cache30.DistributedAckOverflowRegionCCEOffHeapDUnitTest 
testConcurrentEvents
 10976 ms 
com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderDUnitTest
 testGIIDuringDestroy
 10996 ms com.gemstone.gemfire.cache30.DistributedAckOverflowRegionCCEDUnitTest 
testConcurrentEvents
 10997 ms com.gemstone.gemfire.cache30.GlobalRegionCCEDUnitTest 
testConcurrentEvents
 11011 ms 
com.gemstone.gemfire.internal.cache.persistence.PersistentRecoveryOrderOldConfigDUnitTest
 testGIIDuringDestroy
 11019 ms com.gemstone.gemfire.cache30.DistributedAckRegionCCEOffHeapDUnitTest 
testConcurrentEvents
 11046 ms 
com.gemstone.gemfire.management.internal.configuration.SharedConfigurationUsingDirDUnitTest
 updateClusterConfigDirWithTwoLocatorsAndRollingServerRestart
 11127 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InterestListEndpointDUnitTest 
testDirectPutOnServer
 11142 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InterestListEndpointDUnitTest 
testUpdaterThreadIsAliveForFailedEndPoint
 11143 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InterestListEndpointSelectorDUnitTest
 testDirectPutOnServer
 11146 ms com.gemstone.gemfire.cache30.GlobalRegionCCEOffHeapDUnitTest 
testConcurrentEvents
 11146 ms 
com.gemstone.gemfire.internal.cache.tier.sockets.InterestListEndpointDUnitTest 
testInterestListEndpo

Re: Review Request 50607: Update of cq stats causing disk read

[Bruce Schuchardt]

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


Ship it!




Ship It!

- Bruce Schuchardt


On July 29, 2016, 4:58 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50607/
> ---
> 
> (Updated July 29, 2016, 4:58 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Bruce Schuchardt, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This test verifies perf of durable client -queue with overflow. In case of 
> overflow client queue uses LIFO policy. Because of that we put new entry on 
> disk first. But, after putting that entry into queue that thread needs to 
> update Cq stats, which causes that thread to fetch that value again from 
> disk. that hurts performance. we should be updating any(all) client stats 
> before putting that value into disk.
> 
> Using "hw.getClientUpdateMessage()" to update the stats..
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HARegionQueue.java
>  c5746ed 
> 
> Diff: https://reviews.apache.org/r/50607/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Review Request 50607: Update of cq stats causing disk read

[Hitesh Khamesra]

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

Review request for geode, anilkumar gingade, Bruce Schuchardt, and Dan Smith.


Repository: geode


Description
---

This test verifies perf of durable client -queue with overflow. In case of 
overflow client queue uses LIFO policy. Because of that we put new entry on 
disk first. But, after putting that entry into queue that thread needs to 
update Cq stats, which causes that thread to fetch that value again from disk. 
that hurts performance. we should be updating any(all) client stats before 
putting that value into disk.

Using "hw.getClientUpdateMessage()" to update the stats..


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/ha/HARegionQueue.java
 c5746ed 

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


Testing
---


Thanks,

Hitesh Khamesra

[GitHub] incubator-geode issue #218: GEODE-1682: Adding options for starting Geode RE...

[kirklund]

Github user kirklund commented on the issue:

https://github.com/apache/incubator-geode/pull/218
  
Hi @davinash, there was one test failure in precheckin that needs to be 
fixed:

:geode-core:integrationTest


com.gemstone.gemfire.management.internal.cli.commands.HelpCommandsIntegrationTest
 > testOfflineHelp FAILED
org.junit.ComparisonFailure: expected:<...iguration(=value)?]
[PARAMETERS
<...snip...>
use-cluster-configuration
When set to true, the server requests the configuration from 
locator's cluster
configuration service.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): true
start-rest-api
When set to true, will start the REST API service.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): false
http-service-port
Port on which HTTP Service will listen on
Required: false
Default (if the parameter is not specified): 8080
http-service-bind-address
The IP address on which the HTTP Service will be bound.  By 
default, the Server is bound to
all local addresses.
Required: fals]e>
at org.junit.Assert.assertEquals(Assert.java:115)
at org.junit.Assert.assertEquals(Assert.java:144)
at 
com.gemstone.gemfire.management.internal.cli.commands.HelpCommandsIntegrationTest.testOfflineHelp(HelpCommandsIntegrationTest.java:100)

3229 tests completed, 1 failed, 175 skipped
:geode-core:integrationTest FAILED



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

Re: Array of primitives as region values

[Jinmei Liao]

Thank you John for checking it out. I'll create a Jira ticket to capture
the bug.

On Thu, Jul 28, 2016 at 11:58 PM, John Blum  wrote:

> Just tried with several other value-class type specifiers; same Exception.
>
> On Thu, Jul 28, 2016 at 11:54 PM, John Blum  wrote:
>
> > Hi Jinmei-
> >
> > Yes, I have confirmed the same thing.  I have tried specifying a
> > value-class (type) information, but that did not work either...
> >
> > gfsh>debug --state=ON
> > Debug is ON
> >
> > gfsh>get --region=/Example --key=key1
> > --value-class=J[java.lang.Integer.TYPE;Exception occurred. null
> > java.lang.NullPointerException
> > at org.json.JSONObject.populateMap(JSONObject.java:962)
> > at org.json.JSONObject.(JSONObject.java:279)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.json.GfJsonObject.(GfJsonObject.java:73)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.json.GfJsonObject.getJSONObject(GfJsonObject.java:184)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.CommandResponse$Data.(CommandResponse.java:150)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.CommandResponse.(CommandResponse.java:64)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.CommandResponseBuilder.prepareCommandResponseFromJson(CommandResponseBuilder.java:63)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.shell.GfshExecutionStrategy.executeOnRemote(GfshExecutionStrategy.java:252)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:100)
> > at
> >
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:127)
> > at
> >
> com.gemstone.gemfire.management.internal.cli.shell.Gfsh.promptLoop(Gfsh.java:891)
> > at org.springframework.shell.core.JLineShell.run(JLineShell.java:179)
> > at java.lang.Thread.run(Thread.java:745)
> >
> > Perhaps it is time *Gfsh* switched to Jackson rather than the
> *JSONObject*
> > API, which is half-baked at best.
> >
> > -John
> >
> >
> > On Thu, Jul 28, 2016 at 9:53 PM, Jinmei Liao  wrote:
> >
> >> While debugging into Geode, I ran into a problem of putting an array of
> >> primitives as the value of a region entry. I have a java client that
> would
> >> do a put with this:
> >>
> >> int[] testValues = {1, 2, 3};
> >> region.put("key1", testValues);
> >>
> >> Once the data in the server, I used gfsh to a get "get --key=key1
> >> --region=testRegion", I get an error as the result. Turns out the server
> >> has problem turning the primitive arrays into the json strings that
> would
> >> be sent back to gfsh. Is it always like this? What should be the
> expected
> >> behavior?
> >>
> >> Thanks!
> >>
> >> --
> >> Cheers
> >>
> >> Jinmei
> >>
> >
> >
> >
> > --
> > -John
> > 503-504-8657
> > john.blum10101 (skype)
> >
>
>
>
> --
> -John
> 503-504-8657
> john.blum10101 (skype)
>



-- 
Cheers

Jinmei

Re: Review Request 50604: GEODE-1666: Bump Gradle from 2.12 to 2.14

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On July 29, 2016, 2:50 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50604/
> ---
> 
> (Updated July 29, 2016, 2:50 p.m.)
> 
> 
> Review request for geode, Anthony Baker and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1666: Bump Gradle from 2.12 to 2.14
> 
> 
> Diffs
> -
> 
>   gradle/wrapper/gradle-wrapper.properties 
> ec27a3978e43e387385f32e0ad8b1d62359afd07 
> 
> Diff: https://reviews.apache.org/r/50604/diff/
> 
> 
> Testing
> ---
> 
> Run through complete build in concourse
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Review Request 50604: GEODE-1666: Bump Gradle from 2.12 to 2.14

[Mark Bretl]

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



if moving to 2.14, should go to latest maintenance version 2.14.1

- Mark Bretl


On July 29, 2016, 7:50 a.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/50604/
> ---
> 
> (Updated July 29, 2016, 7:50 a.m.)
> 
> 
> Review request for geode, Anthony Baker and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1666: Bump Gradle from 2.12 to 2.14
> 
> 
> Diffs
> -
> 
>   gradle/wrapper/gradle-wrapper.properties 
> ec27a3978e43e387385f32e0ad8b1d62359afd07 
> 
> Diff: https://reviews.apache.org/r/50604/diff/
> 
> 
> Testing
> ---
> 
> Run through complete build in concourse
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Review Request 50604: GEODE-1666: Bump Gradle from 2.12 to 2.14

[Jens Deppe]

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

Review request for geode, Anthony Baker and Dan Smith.


Repository: geode


Description
---

GEODE-1666: Bump Gradle from 2.12 to 2.14


Diffs
-

  gradle/wrapper/gradle-wrapper.properties 
ec27a3978e43e387385f32e0ad8b1d62359afd07 

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


Testing
---

Run through complete build in concourse


Thanks,

Jens Deppe

Build failed in Jenkins: Geode-nightly #544

[Apache Jenkins Server]

See 

Changes:

[jmcallister] GEODE-1694 Add Karen Smoler Miller to committers

[bschuchardt] GEODE-1619

[klund] GEODE-1701: rename GeodePermission as ResourcePermission

[lgallinat] Removing gradle output directories from the eclipse classpath

[agingade] GEODE-1687: Added null check for CQs proxy connection.

[gzhou] This closes #219

--
[...truncated 543 lines...]
:geode-web:signArchives SKIPPED
:geode-web-api:jar
:geode-web-api:javadoc
:geode-web-api:javadocJar
:geode-web-api:sourcesJar
:geode-web-api:war
:geode-web-api:signArchives SKIPPED
:geode-assembly:distTar
:geode-assembly:distZip
:geode-assembly:writeBuildInfo
:geode-assembly:srcDistTar
:geode-assembly:srcDistZip
:geode-assembly:signArchives SKIPPED
:geode-assembly:assemble
:geode-assembly: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-assembly:processTestResources
:geode-assembly:testClasses
:geode-assembly:checkMissedTests
:geode-assembly:installDist
:geode-assembly:test
:geode-assembly:check
:geode-assembly:build
:geode-assembly:distributedTest
:geode-assembly:flakyTest
:geode-assembly:integrationTest
:geode-common:assemble
:geode-common:compileTestJava
:geode-common:processTestResources UP-TO-DATE
:geode-common:testClasses
:geode-common:checkMissedTests
:geode-common:test
:geode-common:check
:geode-common:build
:geode-common:distributedTest
:geode-common:flakyTest
:geode-common:integrationTest
:geode-core:assemble
:geode-core:checkMissedTests
:geode-core:test
:geode-core:check
:geode-core:build
:geode-core:distributedTest
:geode-core:flakyTest
:geode-core:integrationTest
:geode-cq:assemble
:geode-cq:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-cq:processTestResources
:geode-cq:testClasses
:geode-cq:checkMissedTests
:geode-cq: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: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: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:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest

com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest > 
returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite FAILED
com.gemstone.gemfire.test.dunit.RMIException: While invoking 
com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest$$Lambda$20/2040942847.run
 in VM 0 running on Host asf902.gq1.ygridcore.net with 4 VMs
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
at 
com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.putEntriesAndValidateResultsWithRedundancy(LuceneQueriesPeerPRRedundancyDUnitTest.java:106)
at 
com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.returnCorrectResultsWhenCloseCacheHappensOnPartialIndexWrite(LuceneQueriesPeerPRRedundancyDUnitTest.java:87)

Caused by:
java.lang.NullPointerException
at 
com.gemstone.gemfire.cache.lucene.test.LuceneTestUtilities.resumeSender(LuceneTestUtilities.java:123)
at 
com.gemstone.gemfire.cache.lucene.LuceneQueriesPeerPRRedundancyDUnitTest.lambda$putEntriesAndValidateResultsWithRedundancy$84651174$3(LuceneQueriesPeerPRRedundancyDUnitTest.java:106)

78 tests completed, 1 failed
:geode-lucene:distributedTest FAILED
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-pulse:assemble
:geode-pulse:comp