Re: Review Request 53814: GEODE-2100 Add new version of query client server messages

[Dan Smith]

> On Nov. 16, 2016, 6:06 p.m., Dan Smith wrote:
> > What is the JUnit4DistributedTestCase change for?
> 
> Jason Huynh wrote:
> If a previous test failed with suspect strings in 
> tearDownDistributedTestCase, the postTearDown would not get called for the 
> unit test.  This then caused the rest of the tests to fail because any clean 
> up for that specific test was not being done.

Makes sense. Thanks!


- Dan


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


On Nov. 16, 2016, 5:22 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53814/
> ---
> 
> (Updated Nov. 16, 2016, 5:22 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, nabarun nag, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added new versions of messages, preventing CumulativeNonDistinctResults from 
> being sent back to a pre Geode client.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java
>  08c2ecf 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java
>  579a3e1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Query.java
>  a6dc022 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Query651.java
>  51b2a24 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/QueryGeode10.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/QueryWithParametersGeode10.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/JUnit4DistributedTestCase.java
>  838bb29 
> 
> Diff: https://reviews.apache.org/r/53814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 53814: GEODE-2100 Add new version of query client server messages

[Dan Smith]

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


Ship it!




What is the JUnit4DistributedTestCase change for?

- Dan Smith


On Nov. 16, 2016, 5:22 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53814/
> ---
> 
> (Updated Nov. 16, 2016, 5:22 p.m.)
> 
> 
> Review request for geode, Barry Oglesby, nabarun nag, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Added new versions of messages, preventing CumulativeNonDistinctResults from 
> being sent back to a pre Geode client.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommandQuery.java
>  08c2ecf 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/CommandInitializer.java
>  579a3e1 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Query.java
>  a6dc022 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/Query651.java
>  51b2a24 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/QueryGeode10.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/command/QueryWithParametersGeode10.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/test/dunit/internal/JUnit4DistributedTestCase.java
>  838bb29 
> 
> Diff: https://reviews.apache.org/r/53814/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 53745: when a sender was stopped before becoming a primary, the wait thread should be closed

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Nov. 15, 2016, 1:33 a.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53745/
> ---
> 
> (Updated Nov. 15, 2016, 1:33 a.m.)
> 
> 
> Review request for geode, anilkumar gingade and Dan Smith.
> 
> 
> Bugs: geode-2107
> https://issues.apache.org/jira/browse/geode-2107
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a thread leak we found in GEM-933.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/AbstractGatewaySenderEventProcessor.java
>  b41ace4 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderAdvisor.java
>  97cfac7 
> 
> Diff: https://reviews.apache.org/r/53745/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: GMSJoinLeaveJUnitTest format is broken?

[Dan Smith]

Sent that too soon!

I think everyone should always run ./gradlew build before pushing changes
to avoid breaking the build. I'm not sure what the solution is for
spotless, but we should be checking things before pushing them. One thing
to consider is adding a pre-push hook to force a build to run whenever you
try to push something:

incubator-geode> echo "./gradlew build" > .git/hooks/pre-push

-Dan

On Mon, Nov 14, 2016 at 10:36 AM, Dan Smith <dsm...@pivotal.io> wrote:

> Everyone should always run ./gradlew
>
> On Mon, Nov 14, 2016 at 10:35 AM, Bruce Schuchardt <bschucha...@pivotal.io
> > wrote:
>
>> This is fixed now.  I will not apologize for breaking the build though.
>> I formatted the code that I checked in with the provided formatter
>> configuration for Idea and that should pass the spotlessCheck task.
>>
>> We should turn off spotlessCheck until the IDE formatters conform to the
>> spotlessCheck rules.
>>
>>
>> Le 11/14/2016 à 10:27 AM, Kirk Lund a écrit :
>>
>>> * What went wrong:
>>> Execution failed for task ':geode-core:spotlessJavaCheck'.
>>>
>>>> Format violations were found. Run 'gradlew spotlessApply' to fix them.
>>>>
>>> ../../geode/geode-core/src/test/java/org/apache/geode/distri
>>> buted/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>>>
>>> * Try:
>>> Run with --stacktrace option to get the stack trace. Run with --info or
>>> --debug option to get more log output.
>>>
>>> BUILD FAILED
>>>
>>>
>>
>

Re: GMSJoinLeaveJUnitTest format is broken?

[Dan Smith]

Everyone should always run ./gradlew

On Mon, Nov 14, 2016 at 10:35 AM, Bruce Schuchardt 
wrote:

> This is fixed now.  I will not apologize for breaking the build though.  I
> formatted the code that I checked in with the provided formatter
> configuration for Idea and that should pass the spotlessCheck task.
>
> We should turn off spotlessCheck until the IDE formatters conform to the
> spotlessCheck rules.
>
>
> Le 11/14/2016 à 10:27 AM, Kirk Lund a écrit :
>
>> * What went wrong:
>> Execution failed for task ':geode-core:spotlessJavaCheck'.
>>
>>> Format violations were found. Run 'gradlew spotlessApply' to fix them.
>>>
>> ../../geode/geode-core/src/test/java/org/apache/geode/distri
>> buted/internal/membership/gms/membership/GMSJoinLeaveJUnitTest.java
>>
>> * Try:
>> Run with --stacktrace option to get the stack trace. Run with --info or
>> --debug option to get more log output.
>>
>> BUILD FAILED
>>
>>
>

Re: Review Request 53566: GEODE-2078: Fix manifest classpath

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Nov. 8, 2016, 4:23 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53566/
> ---
> 
> (Updated Nov. 8, 2016, 4:23 a.m.)
> 
> 
> Review request for geode, Mark Bretl and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The manifest classpath for *-dependencies.jar was pulling in
> dependencies from geode-pulse and geode-web-api. Filter out those
> projects before collecting the jars.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle cc2518b834fee59d8c7fc91233f2206c6a379c96 
> 
> Diff: https://reviews.apache.org/r/53566/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Gfsh Parsing

[Dan Smith]

+1 for simplifying the parsing and using spring shell.

-Dan

On Fri, Nov 4, 2016 at 1:42 PM, Real Wes  wrote:

> That would be a really good implementation since it would keep production
> code from relying on the formatting of the GFSH return message.  If you did
> —output=json, then the call to the GfshParser could possibly involve
> non-internal classes, which would be even nicer.
>
> > On Nov 4, 2016, at 4:31 PM, Anthony Baker  wrote:
> >
> > Wes, I think it would be interesting if we added a new option
> ‘--output=json’ to better handle the use case you described.  Then you
> could pipe the gfsh command through a json parser like jq.
> >
> > Anthony
> >
> >> On Nov 4, 2016, at 9:51 AM, Real Wes  wrote:
> >>
> >> I call the GFSH Parser from code and rely on the formatting of the
> return message to determine the response. So I’d like to see that code as
> encapsulated in one place.
> >>
> >>> On Nov 4, 2016, at 11:38 AM, Jinmei Liao  wrote:
> >>>
> >>>
> >>> We have several jira issues related to gfsh parsing (GEODE-1598,
> >>> GEODE-1912). After spending some time understanding how the parsing
> works,
> >>> I found out we have three components intertwined together all trying
> to do
> >>> parsing: Gfsh, JoptSimple and Spring Shell. I started an experiment by
> >>> getting rid of Gfsh and JoptSimple parsing and only using Spring
> Shell. The
> >>> outcome is I am able to maintain the current parsing and tabbing
> completion
> >>> capabilities (and fix a few bugs) by removing 40+ files. The only
> >>> difference I see so far lies in the help and hint messages. It seems
> the
> >>> main reason we are using these home backed Gfsh parsing is to provide
> more
> >>> readable help messages. Below are the differences:
> >>>
> >>> Using Spring Shell's provided help:
> >>>
> >>> Using Gfsh Parsing with JoptSimple:
> >>>
> >>>
> >>> I do like the outcome of the latter, but added complexity of the code
> is
> >>> too expensive to bear. So I am asking the community how important it
> is to
> >>> maintain the current style of help? Can we do with the cheaper way by
> just
> >>> using whatever provided by the libraries?
> >>>
> >>> Cheers
> >>>
> >>> Jinmei
> >>>
> >>
> >
>
>

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

[Dan Smith]

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


Fix it, then Ship it!





geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
 (line 666)
<https://reviews.apache.org/r/53401/#comment224260>

Couldn't this just be assertEquals?


- Dan Smith


On Nov. 2, 2016, 8:14 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53401/
> ---
> 
> (Updated Nov. 2, 2016, 8:14 p.m.)
> 
> 
> 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
> 
>

Review Request 53399: Removing some string comparisons in the AttributesDescriptor

[Dan Smith]

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

Review request for geode, Jason Huynh and nabarun nag.


Repository: geode


Description
---

I found this while working on GEODE-1985. AttributesDescriptor does a bunch of 
string comparisons when it could do a single, more efficient instanceof. 

With a microbenchmark I found this sped up reevaluation of an entry when I did 
an indexed query.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/AttributeDescriptor.java
 a11bea0752e8ed8184f0173f81be08b001cb6e19 

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


Testing
---


Thanks,

Dan Smith

Review Request 53398: GEODE-1985: Updating the SAFE_QUERY_TIME after updating indexes

[Dan Smith]

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

Review request for geode, Jason Huynh and nabarun nag.


Repository: geode


Description
---

This is a fix for pretty specific race condition
1) T1 does a put and gets to the point of calling setIndexBufferTime,
but hasn't updated the indexes
2) T2 starts a query and finds the entry in the index even though the
value no longer matches the query
3) T1 finishes the put
4) T2 checks to see if should revaluate the entry, but decides not to
because based on the SAFE_QUERY_TIME value the entry changed before the
query started.

By moving the update to SAFE_QUERY_TIME down, if the an entry
doesn't need reevaluation based on the SAFE_QUERY_TIME, we know the
index was updated before the query started.

There is currently an updateInProgress flag to handle the issue of the
query executing before the SAFE_QUERY_TIME is updated. If the entry is
updated, but not the index, the updateInProgress flag will be set.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
360c6a9f444b41a99bec1a896e660bd506d793ff 

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


Testing
---


Thanks,

Dan Smith

jmh benchmarks

[Dan Smith]

Hi all,

I'd like to add some support for running benchmarks with jmh to geode. Is
this something we're interested in having? JMH is a framework for easily
writing microbenchmarks. It's probably not that useful for large scale
multiple member benchmarks, but it can help us benchmark and optimize
smaller pieces of code.

You can look at this review request for what I want to change and a couple
of example benchmarks:

https://reviews.apache.org/r/53395/

-Dan

Review Request 53395: Adding a geode-benchmark project with support for running jmh benchmarks

[Dan Smith]

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

Review request for geode.


Repository: geode


Description
---

Adding a new project with a couple of simple benchmarks using jmh, to
make it easier for developers to write microbenchmarks of geode.


Diffs
-

  build.gradle 6e82433e81ad832cc753c71873b112b73b81397e 
  geode-benchmarks/build.gradle PRE-CREATION 
  
geode-benchmarks/src/jmh/java/org/apache/geode/cache/benchmark/RangeQueryWithIndexBenchmark.java
 PRE-CREATION 
  
geode-benchmarks/src/jmh/java/org/apache/geode/cache/benchmark/RegionOperationBenchmark.java
 PRE-CREATION 
  settings.gradle 5aaa17ad69d1f3e4d3c2c8af5b8a5667b3fab7d9 

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


Testing
---


Thanks,

Dan Smith

Re: Backwards compatibility for 1.1

[Dan Smith]

+1 for getting Bruc'e's backwards compatibility testing framework in!

-Dan

On Wed, Nov 2, 2016 at 10:50 AM, Anilkumar Gingade <aging...@pivotal.io>
wrote:

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

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

[Dan Smith]

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


Fix it, then Ship it!





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

What's this difference between PDXQueryTestBase and JUnit4PDXQueryTestBase? 
They both seem to be using junit4...



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

Get rid of these log statements.


- Dan Smith


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

Re: Review Request 53243: GEODE-2044 Add to docs tc Server 3.2 for HTTP Session Mgmt module

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 27, 2016, 10:38 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53243/
> ---
> 
> (Updated Oct. 27, 2016, 10:38 p.m.)
> 
> 
> Review request for geode, William Markito and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2044 Add to docs tc Server 3.2 for HTTP Session Mgmt module
> 
> 
> Diffs
> -
> 
>   geode-docs/tools_modules/http_session_mgmt/quick_start.html.md.erb 
> 434a13c760f4898600734cd8b188f26df159c4d5 
> 
> Diff: https://reviews.apache.org/r/53243/diff/
> 
> 
> Testing
> ---
> 
> rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: Review Request 53214: GEODE-2040 Add to docs Tomcat 8.0 and 8.5 for HTTP Session Mgmt module

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 26, 2016, 11:44 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53214/
> ---
> 
> (Updated Oct. 26, 2016, 11:44 p.m.)
> 
> 
> Review request for geode, William Markito and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2040 Add to docs Tomcat 8.0 and 8.5 for HTTP Session Mgmt module
> 
> 
> Diffs
> -
> 
>   geode-docs/tools_modules/http_session_mgmt/quick_start.html.md.erb 
> d065e323ff0b8e4ea4842885a953095c5e30a92e 
>   
> geode-docs/tools_modules/http_session_mgmt/tomcat_setting_up_the_module.html.md.erb
>  a472ab38e6f8214552501eb23aa265130b972d64 
> 
> Diff: https://reviews.apache.org/r/53214/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Karen Miller
> 
>

Re: CI failures due to JMX client heartbeat thread

[Dan Smith]

Just looking at a couple of these bugs, these are fatal level errors. Do
you know what is causing them or what affect this might have?

[fatal 2016/09/29 12:12:03.891 PDT  tid=0x18d]
(tid=397 msgId=39) No longer connected to cc6-co6.gemstone.com[27162].

-Dan

On Wed, Oct 26, 2016 at 4:50 PM, Bruce Schuchardt 
wrote:

> We have 23 CI failure tickets concerning suspect strings from "JMX client
> heartbeat" threads.  I think we should add this to ExpectedStrings.java and
> close these tickets.  The suspect strings are coming from
> javax.management.remote.rmi.RMIConnector and I don't think there's
> anything we can do about them.  Most, if not all, are assigned to security
> or JMX components.
>
>
>GEODE-1858
>GEODE-1955
>GEODE-1492
>GEODE-1539
>GEODE-1538
>GEODE-1773
>GEODE-1922
>GEODE-1482
>GEODE-1475
>GEODE-1480
>GEODE-1481
>GEODE-1826
>GEODE-1825
>GEODE-1820
>GEODE-1878
>GEODE-1879
>GEODE-1877
>GEODE-1875
>GEODE-1876
>GEODE-1499
>GEODE-1476
>GEODE-1869
>GEODE-1769
>
>

Re: GEODE-2036 and documentation practices and procedures

[Dan Smith]

1) +1
2) +1

3)
> I don’t see much value in creating an uber-JIRA for tracking minor doc
changes.  Why not skip it entirely?
I agree with Anthony on this one, there's not much value in having some
catch all JIRA for unrelated changes.

-Dan

On Tue, Oct 25, 2016 at 7:08 PM, Anthony Baker  wrote:

> What I _think_ you are suggesting is using C-T-R (commit-then-review) [1]
> for reasonably well-defined documentation-related changes.  Do you agree?
>
> Here’s why we tag commits with a JIRA:
>
> - we can better understand the reason for a code change by looking at the
> associated JIRA
> - we can scope work in/out of a release by using ‘Fix version’ on the JIRA
> - we can generate release notes by looking at resolved issues for a given
> version
>
> I don’t see much value in creating an uber-JIRA for tracking minor doc
> changes.  Why not skip it entirely?
>
>
> Anthony
>
> [1] https://www.apache.org/foundation/glossary.html#CommitThenReview <
> https://www.apache.org/foundation/glossary.html#CommitThenReview>
>
>
> > On Oct 25, 2016, at 5:45 PM, Karen Miller  wrote:
> >
> > With our documentation now in the same repository as the code, there are
> now
> > some doc-related issues that could use some community consensus. Here are
> > some of my opinions to start the discussion.
> >
> > 1. Create new JIRA tickets for each documentation task, or use the
> existing
> > ticket under
> > which the code is committed for the documentation task?
> >
> >  I'd like to see a combination of both, but use the existing ticket
> > wherever
> > possible. By using the same ticket as the code, the documentation effort
> is
> > less
> > likely to be forgotten.  I certainly think that when a new property is
> > introduced,
> > or a default value is changed, the same ticket can be used.
> >
> >  I think that for large, and new efforts (in the documentation), new
> > tickets are the
> > way to go.
> >
> > 2. Do we need a review effort for all documentation tasks?
> >
> >  My opinion:  no, not for everything.  The bigger the changes, the more
> > likely that
> > a review is warranted.
> >
> > 3. Do we need a new JIRA ticket for each very little documentation
> change?
> >
> >  On this question, my strong opinion is no, we don't need distinct JIRAs.
> > I'd like to propose that we use a single ticket per release that
> > all typo fixes and really small changes are committed under.  No
> > reviews needed. We won't end up with dozens of tickets, each for a tiny
> > change that really needs no community discussion.  If the ticket becomes
> > abused,
> > we can revisit the topic.
> >
> >  I've already created https://issues.apache.org/jira/browse/GEODE-2036
> for
> > just this purpose, as I have a typo that I want to fix.  If no one
> objects,
> > we can
> > use this ticket for all tiny fixes that go with Geode 1.1.0.
>
>

Re: [DISCUSS] Graduation

[Dan Smith]

+1

-Dan

On Tue, Oct 25, 2016 at 5:43 PM, Joey McAllister 
wrote:

> +1
>
> On Tue, Oct 25, 2016 at 5:42 PM Anthony Baker  wrote:
>
> > +1
> >
> > > On Oct 25, 2016, at 5:25 PM, Roman Shaposhnik  wrote:
> > >
> > > Unless somebody objects strongly to my #2 and #3 proposals I'm going
> > > to kick of this thread on private@.
> >
> >
>

Re: 2.0 release in JIRA

[Dan Smith]

And it's gone.

-Dan

On Tue, Oct 25, 2016 at 10:54 AM, Darrel Schneider <dschnei...@pivotal.io>
wrote:

> +1
>
> On Tue, Oct 25, 2016 at 10:28 AM, Swapnil Bawaskar <sbawas...@pivotal.io>
> wrote:
>
> > +1
> >
> > On Tuesday, October 25, 2016, Anthony Baker <aba...@pivotal.io> wrote:
> >
> > > +1
> > >
> > > > On Oct 25, 2016, at 9:44 AM, Dan Smith <dsm...@pivotal.io
> > <javascript:;>>
> > > wrote:
> > > >
> > > > It looks like we already have both a 1.1 and a 2.0 version in JIRA.
> Do
> > we
> > > > need that 2.0 version yet? The only things I see assigned to it seem
> to
> > > be
> > > > assigned to it by mistake. Is it ok to delete that version until
> we're
> > > > actually working on 2.0?
> > > >
> > > > -Dan
> > >
> > >
> >
>

2.0 release in JIRA

[Dan Smith]

It looks like we already have both a 1.1 and a 2.0 version in JIRA. Do we
need that 2.0 version yet? The only things I see assigned to it seem to be
assigned to it by mistake. Is it ok to delete that version until we're
actually working on 2.0?

-Dan

Re: Closing the release in JIRA

[Dan Smith]

I marked it as closed.

-Dan

On Tue, Oct 25, 2016 at 1:08 AM, Swapnil Bawaskar 
wrote:

> Hi,
> After passing the vote on general@incubator, I closed all the issues in
> JIRA that were in RESOLVED state. However, I do not seem to have permission
> to close the release label in JIRA
>  selectedTab=com.atlassian.jira.jira-projects-plugin:version-summary-panel
> >.
> Can someone with permission either mark the release as closed OR give me
> permission to close the relase?
>
> Thanks!
>

Re: more spotless problems on Windows

[Dan Smith]

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 
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: Coding practices/standards

[Dan Smith]

@pivotal.io>
> >>>> wrote:
> >>>>>>>
> >>>>>>>> +1
> >>>>>>>>
> >>>>>>>>> On Oct 21, 2016, at 8:27 AM, Bruce Schuchardt <
> >>>> bschucha...@pivotal.io>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> +1
> >>>>>>>>>
> >>>>>>>>> Le 10/20/2016 à 5:13 PM, Udo Kohlmeyer a écrit :
> >>>>>>>>>> +1
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On 20/10/16 4:56 pm, Mark Bretl wrote:
> >>>>>>>>>>> +1 as well...
> >>>>>>>>>>>
> >>>>>>>>>>> - Pulled changes
> >>>>>>>>>>> - Executed './gradlew clean build' and was successful.
> >>>>>>>>>>> - Modified a couple of random files to test
> >>>>>>>>>>> - Ran './gradlew clean build' again and failed expectedly
> >>>>>>>>>>> - Ran './gradlew spotlessApply', task was successful
> >>>>>>>>>>> - Ran './gradlew clean build' and succeeded
> >>>>>>>>>>>
> >>>>>>>>>>> Great addition! As long as others are good with the formatter,
> >>>> then I
> >>>>>>>> am
> >>>>>>>>>>> good.
> >>>>>>>>>>>
> >>>>>>>>>>> --Mark
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Oct 20, 2016 at 3:40 PM, Kirk Lund <kl...@apache.org>
> >>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> +1 I just added my approval to the PR (and again here)
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Thu, Oct 20, 2016 at 3:25 PM, Jared Stewart <
> >>>> jstew...@pivotal.io
> >>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I have opened a pull request here <
> https://github.com/apache/
> >>>>>>>>>>>>> incubator-geode/pull/268> to enable the Spotless plugin and
> to
> >>>>>>>> switch to
> >>>>>>>>>>>>> the Google Java Style formatter templates.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Oct 18, 2016, at 4:32 PM, Kirk Lund <kl...@pivotal.io>
> >>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> For reference TRAC #38741 was a bug with the summary
> >>>> "EOFException
> >>>>>>>>>>>> during
> >>>>>>>>>>>>>> deserialize on client update with copy-on-read=true"
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Kirk
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Tue, Oct 18, 2016 at 4:27 PM, Jared Stewart <
> >>>>>> jstew...@pivotal.io
> >>>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>> To give everyone an update, using the Google Java Style
> >> eclipse
> >>>>>>>>>>>> template
> >>>>>>>>>>>>>>> there is an issue spotlessCheck where fails for
> >>>>>>>>>>>>>>> geode-core/src/test/java/org/apache/geode/cache30/
> >>>>>>>>>>>>> Bug38741DUnitTest.java
> >>>>>>>>>>>>>>> even if you run it directly after spotlessApply. This needs
> >> to
> >>>> be
> >>>>>>>>>>>>>>> investigated and fixed before I c

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

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 24, 2016, 4:33 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53026/
> ---
> 
> (Updated Oct. 24, 2016, 4:33 p.m.)
> 
> 
> 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: Coding practices/standards

[Dan Smith]

t;>>> - Pulled changes
> >>>>>>>>>> - Executed './gradlew clean build' and was successful.
> >>>>>>>>>> - Modified a couple of random files to test
> >>>>>>>>>> - Ran './gradlew clean build' again and failed expectedly
> >>>>>>>>>> - Ran './gradlew spotlessApply', task was successful
> >>>>>>>>>> - Ran './gradlew clean build' and succeeded
> >>>>>>>>>>
> >>>>>>>>>> Great addition! As long as others are good with the formatter,
> >>> then I
> >>>>>>> am
> >>>>>>>>>> good.
> >>>>>>>>>>
> >>>>>>>>>> --Mark
> >>>>>>>>>>
> >>>>>>>>>> On Thu, Oct 20, 2016 at 3:40 PM, Kirk Lund <kl...@apache.org>
> >>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> +1 I just added my approval to the PR (and again here)
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Thu, Oct 20, 2016 at 3:25 PM, Jared Stewart <
> >>> jstew...@pivotal.io
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> I have opened a pull request here <https://github.com/apache/
> >>>>>>>>>>>> incubator-geode/pull/268> to enable the Spotless plugin and to
> >>>>>>> switch to
> >>>>>>>>>>>> the Google Java Style formatter templates.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Oct 18, 2016, at 4:32 PM, Kirk Lund <kl...@pivotal.io>
> >>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For reference TRAC #38741 was a bug with the summary
> >>> "EOFException
> >>>>>>>>>>> during
> >>>>>>>>>>>>> deserialize on client update with copy-on-read=true"
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Kirk
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Tue, Oct 18, 2016 at 4:27 PM, Jared Stewart <
> >>>>> jstew...@pivotal.io
> >>>>>>>>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>> To give everyone an update, using the Google Java Style
> >> eclipse
> >>>>>>>>>>> template
> >>>>>>>>>>>>>> there is an issue spotlessCheck where fails for
> >>>>>>>>>>>>>> geode-core/src/test/java/org/apache/geode/cache30/
> >>>>>>>>>>>> Bug38741DUnitTest.java
> >>>>>>>>>>>>>> even if you run it directly after spotlessApply. This needs
> >> to
> >>> be
> >>>>>>>>>>>>>> investigated and fixed before I can open a pull request to
> >>> enable
> >>>>>>>>>>>> spotless.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Oct 14, 2016, at 4:57 PM, Dan Smith <dsm...@pivotal.io>
> >>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> +1 - The formatting looks better now.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> -Dan
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Thu, Oct 13, 2016 at 11:06 AM, Jared Stewart <
> >>>>>>> jstew...@pivotal.io
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>> I agree that the formatter needs fixing up.  Our wiki <
> >>>>>>>>>>>>>>

Re: Updating Swagger

[Dan Smith]

Looks great to me! 

 Original message 
From: Kevin Duling  
Date: 10/20/16  12:22 PM  (GMT-08:00) 
To: dev@geode.incubator.apache.org 
Subject: Re: Updating Swagger 

I've updated the page to appear as follows.  Any feedback is welcome.

https://drive.google.com/file/d/0B-lWOyam73gWb0hWT1Jtd1loeFE/view?usp=sharing

On Thu, Oct 20, 2016 at 11:40 AM, Kevin Duling  wrote:

> I'm updating Swagger to the Swagger2 specification and the new landing
> page has different fields than the old one.  I've populated most of them
> with some possible values and am looking for feedback.  I've placed a
> screenshot at https://drive.google.com/open?id=0B-
> lWOyam73gWdWZjVDloVF82VnM
>
> Some of the changes I think need to be made:
>
>    - Change the "see more" to point to geode.apache.org
>    - Change the "Created by" text to "the Apache Geode Community"
>    - Change the email to dev@geode.incubator.apache.org
>    - I need to know what version number to put in for the api.  I don't
>    know if that's been defined, but I can't leave it as 'VERSION'
>
> Things I can't change easily:
>
>    - "Created by _"  This header is generated by the Contact object
>    sent in.
>    - "See more at " Another auto-generated header
>    - "Contact the developer" I can change what the link points to, but
>    not the text
>    - "API VERSION: " cannot be suppressed
>    - Can't suppress the subject in the email link
>    - almost everything in the gray text
>
>
>

Re: jvsd

[Dan Smith]

Hi Dor,

jvsd hasn't yet been merged to develop, so for now you still have to check
out the feature/GEODE-78 branch and build it from source. Here are some
instructions:

https://github.com/apache/incubator-geode/blob/feature/GEODE-78/geode-jvsd/README.md

0-Dan


On Wed, Oct 19, 2016 at 1:43 AM, Dor Ben Dov  wrote:

> Hi,
>
> Where can I get the latest version of it ?
>
>
> Regards,
> Dor
>
> This message and the information contained herein is proprietary and
> confidential and subject to the Amdocs policy statement,
> you may review at http://www.amdocs.com/email_disclaimer.asp
>

Re: Review Request 53001: GEODE-1927: more protection from seeing com.gemstone.gemfire packaged objects

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 18, 2016, 10:05 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53001/
> ---
> 
> (Updated Oct. 18, 2016, 10:05 p.m.)
> 
> 
> Review request for geode, Hitesh Khamesra, Udo Kohlmeyer, and Dan Smith.
> 
> 
> Bugs: GEODE-1927
> https://issues.apache.org/jira/browse/GEODE-1927
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> DeadlockDetector can read an archive of dependencies across the distributed 
> system.  This adds a small ObjectInputStream modification to its method that 
> reads these archives to let it handle those created before the package rename.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/distributed/internal/deadlock/DeadlockDetector.java
>  2c70418e53b25edd3ae7cfe801e8f4b92ca1c3ec 
> 
> Diff: https://reviews.apache.org/r/53001/diff/
> 
> 
> Testing
> ---
> 
> manual testing with an old archive
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

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

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 12, 2016, 5:52 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52793/
> ---
> 
> (Updated Oct. 12, 2016, 5:52 p.m.)
> 
> 
> 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
> 
>

Re: Hosting the docs (was Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2)

[Dan Smith]

Along these lines, should we distributing the docs with the binary release?
Or maybe just providing a link to them? The README.md shipped with 1.0.RC2
points to http://geode.docs.pivotal.io/ .

What about geode-examples? Should that be part of the binary release?

-Dan

On Mon, Oct 17, 2016 at 2:21 PM, Joey McAllister 
wrote:

> @Roman: Nothing that I can think of, apart from giving the community time
> to offer feedback here (which, it looks like, is all positive). William
> Markito and I were able to build and test a local version of the website
> with the docs included.
>
> Based on the +1s here, I'd like to go ahead and push the current docs to
> the website. I'll also document the process in a README.
>
> On Mon, Oct 17, 2016 at 12:49 PM Roman Shaposhnik 
> wrote:
>
> > On Mon, Oct 17, 2016 at 10:57 AM, Anthony Baker 
> wrote:
> > > Since the geode docs have now been merged to the develop branch, let’s
> > start
> > > hosting them on http://geode.apache.org.  Thoughts?
> >
> > Huge +1! Anything stopping you from pushing the first update and start
> > maintaining
> > it a'la Hadoop:
> > https://hadoop.apache.org/docs/
> > ?
> >
> > Thanks,
> > Roman.
> >
>

Review Request 52963: GEODE-388: Deprecating DynamicRegionFactory

[Dan Smith]

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

Review request for geode and Darrel Schneider.


Repository: geode


Description
---

Marking DynamicRegionFactory as deprecated.


Diffs
-

  geode-core/src/main/java/org/apache/geode/cache/DynamicRegionFactory.java 
3cfa73b840785cab94d4ca54aac1338304a20f30 

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


Testing
---


Thanks,

Dan Smith

Re: Hosting the docs (was Re: [VOTE] Release Apache Geode (incubating) 1.0.0-incubating - RC2)

[Dan Smith]

+1 - I was going to ask about this on the release thread. Let's put them up
on geode.apache.org!

-Dan

On Mon, Oct 17, 2016 at 11:33 AM, Swapnil Bawaskar 
wrote:

> +1, It would be great to have this by the time we put the vote out on
> general@incubator
>
> On Mon, Oct 17, 2016 at 10:59 AM, Joey McAllister 
> wrote:
>
> > Only a very enthusiastic +1. :)
> >
> > On Mon, Oct 17, 2016 at 10:57 AM Anthony Baker 
> wrote:
> >
> > > Since the geode docs have now been merged to the develop branch, let’s
> > > start hosting them on http://geode.apache.org.  Thoughts?
> > >
> > > Anthony
> > >
> > >
> > > On Oct 15, 2016, at 5:51 PM, Swapnil Bawaskar 
> > > wrote:
> > >
> > >
> > > The documentation on how to install and use Apache Geode are hosted
> > > on pivotal.io:
> > >   http://geode.docs.pivotal.io
> > >
> > >
> > >
> >
>

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

[Dan Smith]

+1

Checked
  * signatures
  * maven repo with simple sample app
  * command line test through gfsh
  * built the source

Checked it with this thing:
https://github.com/upthewaterspout/geode-release-check

On Mon, Oct 17, 2016 at 11:55 AM, William Markito 
wrote:

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

Review Request 52903: Adding a docker container to build and view the geode docs

[Dan Smith]

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

Review request for geode, Anthony Baker, Joey McAllister, and Karen Miller.


Repository: geode


Description
---

Adding a docker container to build and view the geode docs


Diffs
-

  dev-tools/docker/docs/Dockerfile PRE-CREATION 
  dev-tools/docker/docs/build-docs.sh PRE-CREATION 
  dev-tools/docker/docs/build-image-common.sh PRE-CREATION 
  dev-tools/docker/docs/view-docs.sh PRE-CREATION 

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


Testing
---

Adding some scripts that can build and view the docs using a docker container.


Thanks,

Dan Smith

Re: Coding practices/standards

[Dan Smith]

+1 - The formatting looks better now.

-Dan

On Thu, Oct 13, 2016 at 11:06 AM, Jared Stewart <jstew...@pivotal.io> wrote:

> I agree that the formatter needs fixing up.  Our wiki <
> https://cwiki.apache.org/confluence/display/GEODE/Code+Style+Guide> says
> that we follow the Google Java Style guide, but that is not actually what’s
> in our formatter templates.  I pushed a new branch <https://github.com/
> jaredjstewart/incubator-geode/tree/spotlessPluginGoogleStyle> that points
> spotless at the actual Google Java Style template, and I think it makes
> both of the examples you found look better.
>
> > On Oct 13, 2016, at 10:11 AM, Dan Smith <dsm...@pivotal.io> wrote:
> >
> > +1 for adding this to ./gradlew build
> >
> > But I think we might want to fix up the formatter a bit before
> reformatting
> > the code. I tried running spotlessApply, and it did some unfortunate
> > reformatting of code to make it less readable.
> >
> > One problem is with method chaining. We have a few different factory APIs
> > that encourage method chaining, and it put all the method calls on a
> single
> > line. For example here's one change:
> >
> > -ClientCacheFactory ccf = new ClientCacheFactory()
> > -
> > .addPoolServer(NetworkUtils.getServerHostName(server1.getHost()), port)
> > -.set(SECURITY_CLIENT_AUTH_INIT,
> > UserPasswordAuthInit.class.getName() + ".create")
> > -.set(SECURITY_PREFIX+"username", "root")
> > -.set(SECURITY_PREFIX+"password", "root");
> > +ClientCacheFactory ccf = new
> > ClientCacheFactory().addPoolServer(NetworkUtils.
> getServerHostName(server1.getHost()),
> > port).set(SECURITY_CLIENT_AUTH_INIT, UserPasswordAuthInit.class.getName()
> +
> > ".create").set(SECURITY_PREFIX + "username", "root").set(SECURITY_PREFIX
> +
> > "password", "root");
> >
> > I see a similar problem where it put array initialization all on a single
> > line:
> >
> > +  public void testMultiColOrderByWithIndexResultWithProjection() throws
> > Exception {
> > String queries[] = {
> > // Test case No. IUMR021
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 order by ID desc, pkid desc ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 order by ID asc, pkid asc ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 and ID < 20 order by ID asc, pkid asc ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 and ID < 20 order by ID desc , pkid desc",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID >= 10 and ID <= 20 order by ID desc, pkid asc ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID >= 10 and ID <= 20 order by ID asc, pkid desc",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID != 10 order by ID asc , pkid desc",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID != 10 order by ID desc, pkid asc ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 order by ID desc, pkid desc limit 5",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 order by ID asc, pkid asc limit 5",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 and ID < 20 order by ID asc, pkid desc limit 5 ",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID > 10 and ID < 20 order by ID desc, pkid asc limit 5",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID >= 10 and ID <= 20 order by ID desc, pkid desc limit 5",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID >= 10 and ID <= 20 order by ID asc, pkid asc limit 5",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID != 10 order by ID asc , pkid desc limit 10",
> > -"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1
> > where ID != 10 ord

Re: GEODE-1466: geode.properties

[Dan Smith]

-1 for including any of this in the 1.0 release. Let's get that release out
the door!

-Dan

On Thu, Oct 13, 2016 at 2:26 PM, Udo Kohlmeyer 
wrote:

> If such a change is to be introduced.. maybe we call it `SYSTEM_PREFIX` or
> something more generic that we could use within the Geode.
>
> Then we could hopefully cover many to most `gemfire` vs `geode` renaming.
>
> But I agree with @Anthony, if we aren't 100% certain about a change then
> we should hold off until the next release. There is always tomorrow. :D
>
> --Udo
>
>
>
> On 14/10/16 8:05 am, Swapnil Bawaskar wrote:
>
>> How about introducing a new GEMFIRE_FILE_PREFIX attribute that will
>> default
>> to "geode" while leaving GEMFIRE_PREFIX default to "gemfire"? Is this
>> something that will work?
>>
>> On Thu, Oct 13, 2016 at 1:48 PM, Anthony Baker  wrote:
>>
>> Hmmm, you would think it would be easier to change a file name :-)
>>>
>>> I don’t think we should be pushing destabilizing changes into a release
>>> branch.  If the changes aren’t ready now we always pick them up for the
>>> next release.
>>>
>>> Anthony
>>>
>>> On Oct 13, 2016, at 1:13 PM, Kirk Lund  wrote:

 I'm currently working with Jared and we have spent a few days working
 on GEODE-1466. We've been trying to get geode to the point where it can
 automatically search for, find and use either geode.properties or
 gemfire.properties (preferring geode.properties if both are found).

 We were intending to break this up into three subtasks with the hope of
 including #1 in Geode 1.0.0 incubating:

 1) locating geode.properties and gemfire.properties if user has not
 specified a specific properties file

 2) support specifying geode configuration properties with system

>>> properties
>>>
 geode. as well as gemfire.

 ex: -Dgemfire.off-heap-memory-size=40g or -Dgeode.off-heap-memory-size=

>>> 40g
>>>
 3) modify all other system properties in geode to support alias of

>>> gemfire
>>>
 as well as geode where the name of the system property currently
 contains
 gemfire

 ex: -Dgemfire.Query.VERBOSE=true or -Dgeode.Query.VERBOSE=true

 The community is planning to create the Geode 1.0.0 incubating RC

>>> tomorrow.
>>>
 The work we have completed so far involves modifying geode to search for
 both geode.properties and gemfire.properties to use whichever one is

>>> found.
>>>
 This turns out to be too complex to complete by tomorrow (send me a
 email
 directly if you want more detailed info which mostly involves
 DistributionConfig and ConfigSource).

 In order to complete this in time, we need to use a different strategy.
 Instead of looking for geode.properties first and then

>>> gemfire.properties,
>>>
 we are proposing the following change to DistributionConfig:

 Change the GEMFIRE_PREFIX = "gemfire." constant to be configurable by a
 system property and change the default to be "geode." This places a

>>> greater
>>>
 burden on the user who is migrating from GemFire to Geode but doesn't

>>> want
>>>
 to rename gemfire.properties or gemfire system properties. By default,
 Geode would search for geode.properties unless the user specifies a new
 system property with a different prefix ("gemfire."):

 String GEMFIRE_PREFIX = PropertiesPrefix.getGemfireOrGeodePrefix();

 Example of overriding this to be "gemfire.":

 -DgeodePropertiesPrefix="gemfire."
 or
 -DgeodePropertiesPrefix="gemfire"

 (we'll add the "." for you if you leave it out)

 Pivotal or other vendors could also alter this prefix as they see fit.

 There are 453 lines of production code that refer to this GEMFIRE_PREFIX
 constant. For example, every system property that contains "gemfire." is
 currently referring to the constant, so they would also be altered to be
 "geode." by default. The JMX notifications also refer to GEMFIRE_PREFIX
 such as: GEMFIRE_PREFIX + "distributedsystem.cache.client.joined".

 Does anyone know if anything referring to GEMFIRE_PREFIX is persisted in
 some way that would break if we make this change? For example, if we
 persist any strings built with this constant to a diskstore, then

>>> recovery
>>>
 from that diskstore would be broken if the prefix value is "geode."

>>> during
>>>
 recovery of an old diskstore.

 Also, a user could conceivably override the GEMFIRE_PREFIX in some

>>> members
>>>
 of a cluster but not others which could break things in unexpected ways.

 One more note: While reviewing uses of GEMFIRE_PREFIX we noticed that
 AgentUtil supports "GEMFIRE" (hardcoded) and GEMFIRE_PREFIX+".home" env
 vars while all of the online docs specify setting GEMFIRE_HOME as an env
 var. I suspect this 

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

[Dan Smith]

Yet one more reason to run ./gradlew build *before* pushing changes to
develop

You can automate this by adding a pre-push trigger to your git repo. This
will only do the push if the build succeeds:

echo "./gradlew build" > .git/hooks/pre-push
chmod u+x .git/hooks/pre-push

You can do git push --no-verify to skip the check if you want to.

-Dan

On Thu, Oct 13, 2016 at 9:07 AM, Jared Stewart  wrote:

> This file was accidentally committed in GEODE-999. Jinmei removed it from
> develop this morning after we saw the RAT failed last night.  I haven’t
> figured out yet what generated the file in the first place.
>
> > On Oct 13, 2016, at 9:04 AM, Anthony Baker  wrote:
> >
> > Anyone know why this file was generated by the build?  It shows up in
> the rat report.
> >
> > !? /home/jenkins/jenkins-slave/workspace/Geode-nightly/
> artifacts-jstewartgeode999/test/gemfire-jstewartgeode999-files.tgz
> >
> > Anthony
> >
> >
> >> Begin forwarded message:
> >>
> >> From: Apache Jenkins Server 
> >> Subject: Build failed in Jenkins: Geode-nightly #621
> >> Date: October 13, 2016 at 8:36:21 AM PDT
> >> To: dev@geode.incubator.apache.org, jil...@pivotal.io, n...@pivotal.io
> >> Reply-To: dev@geode.incubator.apache.org
> >>
> >> See 
> >>
> >> Changes:
> >>
> >> [jiliao] GEODE-1986: correctly set the flag indicating if cluster
> configuration
> >>
> >> [jiliao] GEODE-1979: refactor SecurityClusterConfig to remove the
> flakiness.
> >>
> >> [jiliao] GEODE-999: Converted from Firefox driver to PhantomJS driver
> to run
> >>
> >> [jiliao] GEODE-1966: Unauthorized users cannot access pulseVersion
> details
> >>
> >> [jiliao] GEODE-1532: Fix Pulse Clickjacking vuln.
> >>
> >> [nnag] GEODE-1978: Slowing down the receivers
> >>
> >> --
> >> [...truncated 407 lines...]
> >> :geode-rebalancer:jar
> >> :geode-rebalancer:javadoc
> >> :geode-rebalancer:javadocJar
> >> :geode-rebalancer:sourcesJar
> >> :geode-rebalancer:signArchives SKIPPED
> >> :geode-wan:jar
> >> :geode-wan:javadoc
> >> :geode-wan:javadocJar
> >> :geode-wan:sourcesJar
> >> :geode-wan:signArchives SKIPPED
> >> :geode-web:javadoc UP-TO-DATE
> >> :geode-web:javadocJar
> >> :geode-web:sourcesJar
> >> :geode-web:war
> >> :geode-web:signArchives SKIPPED
> >> :geode-web-api:javadoc nightly/ws/geode-web-api/src/main/java/org/apache/geode/
> rest/internal/web/controllers/CommonCrudController.java>:196: warning -
> @return tag has no arguments.
> >>
> >> 1 warning
> >> :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: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:distributedTest
> >> :geode-common:flakyTest
> >> :geode-common:integrationTest
> >> :geode-core:assemble
> >> :geode-core:checkMissedTests
> >> :geode-core:test
> >> :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: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: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
> >> 

Re: Coding practices/standards

[Dan Smith]

 description, createTime, pkid FROM
/portfolio1 pf1 where ID > 10 and ID < 20 order by ID asc, pkid desc limit
5 ", "SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1 where
ID > 10 and ID < 20 order by ID desc, pkid asc limit 5", "SELECT   ID,
description, createTime, pkid FROM /portfolio1 pf1 where ID >= 10 and ID <=
20 order by ID desc, pkid desc limit 5", "SELECT   ID, description,
createTime, pkid FROM /portfolio1 pf1 where ID >= 10 and ID <= 20 order by
ID asc, pkid asc limit 5", "SELECT   ID, description, createTime, pkid FROM
/portfolio1 pf1 where ID != 10 order by ID asc , pkid desc limit 10",
"SELECT   ID, description, createTime, pkid FROM /portfolio1 pf1 where ID
!= 10 order by ID desc, pkid desc limit 10",
+
+};





On Thu, Oct 13, 2016 at 9:51 AM, Jared Stewart <jstew...@pivotal.io> wrote:

> The task is fully suppressible with -x spotlessCheck.  Also, if you have
> any formatter errors you can automatically fix them with 'gradle
> spotlessApply’.
>
> > On Oct 13, 2016, at 9:40 AM, Kevin Duling <kdul...@pivotal.io> wrote:
> >
> > If we made formatting a warning, then people would probably quickly
> ignore
> > it.
> > If we made formatting an error, we need to be sure we don't get in to the
> > situation where 's formatter is not in agreement with
> the
> > build's checker.
> >
> > I can live with an additional 17 seconds as well.  And Jared's already
> > reduced the build time locally by 50%.  But I still want the ability to
> > suppress the check similar to -x javadoc.
> >
> > On Wed, Oct 12, 2016 at 9:58 PM, William Markito <wmark...@pivotal.io>
> > wrote:
> >
> >> This sounds really good to me as well.  +1
> >>
> >> On Wed, Oct 12, 2016 at 4:13 PM, Jared Stewart <jstew...@pivotal.io>
> >> wrote:
> >>
> >>> This is running locally on my laptop.  Since Spotless is only doing
> code
> >>> formatting and not any other static analysis, it already has 0 errors.
> >>> (Other than, of course, formatting not consistent with the template.)
> >>>
> >>>> On Oct 12, 2016, at 4:11 PM, Kenneth Howe <kh...@pivotal.io> wrote:
> >>>>
> >>>> Agree with Mark, this has to work with 0 errors before it would be
> >>> useful in precheckin. I think I could live with an additional 17
> seconds
> >>> most of the time for running the spotlessCheck as suggested.
> >>>>
> >>>> Jared, Is that 17 seconds running locally on your laptop or on a more
> >>> capable machine?
> >>>>
> >>>> Ken
> >>>>
> >>>>> On Oct 12, 2016, at 3:39 PM, Jared Stewart <jstew...@pivotal.io>
> >> wrote:
> >>>>>
> >>>>> If you want to try it out, I pushed a branch to my Geode repo that
> >>> contains this change:
> >>>>> https://github.com/jaredjstewart/incubator-geode/tree/spotlessPlugin
> >> <
> >>> https://github.com/jaredjstewart/incubator-geode/tree/spotlessPlugin>
> >>>>>
> >>>>>> On Oct 12, 2016, at 2:27 PM, Darrel Schneider <
> dschnei...@pivotal.io
> >>>
> >>> wrote:
> >>>>>>
> >>>>>> I like Dan's idea of catching formatting issues earlier but I think
> >>> adding
> >>>>>> 5-10 minutes to "build" would be too much. Currently when I'm trying
> >>> to do
> >>>>>> a quick build I use -xjavadoc. I'd probably do the same for this
> >>> target if
> >>>>>> it was part of build until I'm ready to do a precheckin.
> >>>>>>
> >>>>>> Mark, wouldn't running the formatter on all our java files and
> >> checking
> >>>>>> them in get these issues down to 0?
> >>>>>>
> >>>>>> On Wed, Oct 12, 2016 at 12:53 PM, Udo Kohlmeyer <
> >> ukohlme...@pivotal.io
> >>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> +1 - adding checkstyle to precheckin.
> >>>>>>>
> >>>>>>> If the developer uses the provided templates ( eclipse + intellij)
> >>> then
> >>>>>>> most of the formatting issues should be handled before precheckin.
> >>> Also, if
> >>>>>>> a developer has a questionable coding style, that should lessen as
> >&

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

[Dan Smith]

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

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

Re: Review Request 52796: GEODE-1981: Synchronizing the ResultCollector when adding results

[Dan Smith]

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



Based on feedback from Naba, I'll rework this to just wrap the result collector 
in a synchronized result collector, to avoid places where we might be accessing 
this thing without synchronization.

- Dan Smith


On Oct. 12, 2016, 6:12 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52796/
> ---
> 
> (Updated Oct. 12, 2016, 6:12 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. One code path was already
> synchronizing on the collector when adding results. However, if the
> function returned an exception we were not synchronizing.
> 
> 
> 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/ExecuteRegionFunctionOp.java
>  ae08ac0affdef7f2270f68da5622194be8fd009f 
>   
> geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionSingleHopOp.java
>  51ea8e4fbc64acbbd1165856a2dd09704d63e857 
> 
> Diff: https://reviews.apache.org/r/52796/diff/
> 
> 
> Testing
> ---
> 
> Run the test in this bug 500 times with and without this fix. Without the fix 
> it failed 11 times, which the fix it passed every time. Running precheckin on 
> these changes.
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Coding practices/standards

[Dan Smith]

Seems like it should run as part of the build target. The only reason to
make it part of precheckin is if it takes a long time, otherwise people
should get fast feedback they need to change their code before they push.

-Dan

On Wed, Oct 12, 2016 at 11:24 AM, Jared Stewart <jstew...@pivotal.io> wrote:

> +1 to running during the precheckin target as well as Travis CI
>
> On Oct 12, 2016 11:20 AM, "Darrel Schneider" <dschnei...@pivotal.io>
> wrote:
>
> > If Travis CI is only run on pull requests then that is not enough because
> > committers do not submit pull requests. Having it run during the gradle
> > build or precheckin target is also needed. In addition to that I also
> > wanted PRs to be checked.
> >
> >
> > On Wed, Oct 12, 2016 at 11:12 AM, Jared Stewart <jstew...@pivotal.io>
> > wrote:
> >
> > > It would certainly be necessary to make sure that the code style to be
> > > enforced is sensible, e.g. doe not use wildcard imports.  We would also
> > > want to make one large commit to format all existing code before
> turning
> > > this on.
> > >
> > > Mark - Thank you for the information about the existing setup.
> > >
> > > Mark, Darrel, Kevin - Given all of your comments, I think it might make
> > > more sense to add the flag to enable it in Travis CI rather than as
> part
> > > of  the build.  This way your build pass regardless of whitespace, but
> > the
> > > CI job would fail on PRs if they did not adhere to the standard
> > formatting.
> > >
> > > Anthony - It doesn’t seem to me that turning this on would have the
> > effect
> > > of combining reformatting commits and logic changes.  Rather, since all
> > > code would already be formatted, there would no longer be any
> > reformatting
> > > commits except for single large commits when the code style file was
> > > updated.
> > >
> > > > On Oct 12, 2016, at 11:01 AM, Bruce Schuchardt <
> bschucha...@pivotal.io
> > >
> > > wrote:
> > > >
> > > > I like the idea of doing this but I don't think Checkstyle should be
> > > enabled until all of the code is reformatted.
> > > >
> > > > Also, last time I checked there was still a problem with the IntelliJ
> > > auto-format settings.  It still used wildcard imports, which I believe
> we
> > > don't allow.  I've manually changed my settings in Editor->Code
> > Style->Java
> > > to "Use single class import" to correct that problem.  I couldn't see
> how
> > > to get Gradle to do it.
> > > >
> > > >
> > > > Le 10/12/2016 à 10:28 AM, Anthony Baker a écrit :
> > > >> Source code with a consistent look-and-feel makes it easier for
> people
> > > to join the project community and contribute.
> > > >>
> > > >> Let’s continue to keep reformatting commits separate from logic
> > > changes—otherwise it’s too hard to review.
> > > >>
> > > >> Anthony
> > > >>
> > > >>> On Oct 12, 2016, at 10:06 AM, Dan Smith <dsm...@pivotal.io> 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 <
> jstew...@pivotal.io
> > >
> > > wrote:
> > > >>>
> > > >>>> I would like to advocate for adding a Checkstyle <
> http://checkstyle
> > .
> > > >>>> sourceforge.net/> or Spotless <https://github.com/diffplug/
> 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.
> > > >
> > >
> > >
> >
>

Review Request 52796: GEODE-1981: Synchronizing the ResultCollector when adding results

[Dan Smith]

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

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. One code path was already
synchronizing on the collector when adding results. However, if the
function returned an exception we were not synchronizing.


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/ExecuteRegionFunctionOp.java
 ae08ac0affdef7f2270f68da5622194be8fd009f 
  
geode-core/src/main/java/org/apache/geode/cache/client/internal/ExecuteRegionFunctionSingleHopOp.java
 51ea8e4fbc64acbbd1165856a2dd09704d63e857 

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


Testing
---

Run the test in this bug 500 times with and without this fix. Without the fix 
it failed 11 times, which the fix it passed every time. Running precheckin on 
these changes.


Thanks,

Dan Smith

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

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 12, 2016, 5:21 p.m., nabarun nag wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52789/
> ---
> 
> (Updated Oct. 12, 2016, 5:21 p.m.)
> 
> 
> 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

[Dan Smith]

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

Review Request 52759: GEODE-1991: Removing sleeps from HARegionQueueJUnitTest

[Dan Smith]

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

Review request for geode, nabarun nag and xiaojian zhou.


Repository: geode


Description
---

Getting rid of a bunch of sleeps in HARegionQueueJUnitTest to fix a
bunch of tests with race conditions. Tests of expiration were sleeping
for short amounts of time and then asserting that expiration happened or
didn't. Changing these sleeps to use Awailitily.


Diffs
-

  
geode-core/src/test/java/org/apache/geode/internal/cache/ha/BlockingHARegionQueueJUnitTest.java
 48fb3a2769994233ea7c899e324506c102517456 
  
geode-core/src/test/java/org/apache/geode/internal/cache/ha/HARegionQueueJUnitTest.java
 37047583d477c06ac9788ba5df960fe74b225229 

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


Testing
---


Thanks,

Dan Smith

Re: Review Request 52750: GEODE-1985: Check for index expression reevalaution using a time window

[Dan Smith]

> On Oct. 11, 2016, 10:11 p.m., Jason Huynh wrote:
> > geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java,
> >  line 371
> > <https://reviews.apache.org/r/52750/diff/1/?file=1531244#file1531244line371>
> >
> > Was this intended for this diff?

Ah, that was supposed to be a separate change. Thanks!


> On Oct. 11, 2016, 10:11 p.m., Jason Huynh wrote:
> > geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java,
> >  line 173
> > <https://reviews.apache.org/r/52750/diff/1/?file=1531243#file1531243line173>
> >
> > Would you be able to remove/modify this comment a bit?  Mostly remove 
> > the bug number as it's not a geode number any more

Sure, I'll update that.


- Dan


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


On Oct. 11, 2016, 9:53 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52750/
> ---
> 
> (Updated Oct. 11, 2016, 9:53 p.m.)
> 
> 
> Review request for geode, Jason Huynh and nabarun nag.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Changing the logic for how to we check to see if an entry may have been
> concurrently modified while an indexed query is in progress.
> 
> The new logic just has a time window, defaulting to 10 minutes. If the
> entry was changed less than 10 minutes for the query started, we will
> reevaluate the index expression to make sure the entry is still valid.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java
>  8ef82f1bee9831fa50a93f87bb9ed0b644a542b4 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java
>  84ba926ee35638c4263a0d93a8be3fef1e2c5f7f 
>   geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
> 46ccd47e96e75a8c4c6f3075b65a2d2447043213 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/IndexManagerJUnitTest.java
>  c7633ea05b0f8a90baf0c8f9e9849480421ebd45 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/AbstractIndexMaintenanceIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/CompactRangeIndexMaintenanceNoReevaluationIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/RangeIndexAPIJUnitTest.java
>  7cc2c12f80ba4248edca9035bbdfd839d20f70ad 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionQueryDUnitTest.java
>  1160d4bdb755e39a2a5c52fb167b86e760e0ae88 
> 
> Diff: https://reviews.apache.org/r/52750/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Deprecate DynamicRegionFactory

[Dan Smith]

I'd like to reopen the discussion about deprecating
DynamicRegionFactory. This is some old crufty code I don't think we
want anyone to use. I see we had a ticket to deprecated it
(GEODE-388), but we chose not to do it because we don't have an
alternative API to create regions from the client (GEODE-215).

The thing is, there is a pretty easy workaround to use functions to
create regions from the client. Personally I'd recommend that over
DynamicRegionFactory. Can we just deprecate DynamicRegionFactory now
and implement GEODE-215 later?

-Dan

Review Request 52750: GEODE-1985: Check for index expression reevalaution using a time window

[Dan Smith]

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

Review request for geode, Jason Huynh and nabarun nag.


Repository: geode


Description
---

Changing the logic for how to we check to see if an entry may have been
concurrently modified while an indexed query is in progress.

The new logic just has a time window, defaulting to 10 minutes. If the
entry was changed less than 10 minutes for the query started, we will
reevaluate the index expression to make sure the entry is still valid.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java
 8ef82f1bee9831fa50a93f87bb9ed0b644a542b4 
  
geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
84ba926ee35638c4263a0d93a8be3fef1e2c5f7f 
  geode-core/src/main/java/org/apache/geode/internal/cache/LocalRegion.java 
46ccd47e96e75a8c4c6f3075b65a2d2447043213 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/IndexManagerJUnitTest.java
 c7633ea05b0f8a90baf0c8f9e9849480421ebd45 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/AbstractIndexMaintenanceIntegrationTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/CompactRangeIndexMaintenanceNoReevaluationIntegrationTest.java
 PRE-CREATION 
  
geode-core/src/test/java/org/apache/geode/cache/query/internal/index/RangeIndexAPIJUnitTest.java
 7cc2c12f80ba4248edca9035bbdfd839d20f70ad 
  
geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionQueryDUnitTest.java
 1160d4bdb755e39a2a5c52fb167b86e760e0ae88 

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


Testing
---


Thanks,

Dan Smith

Re: Review Request 52575: GEODE-1962: increment notQueuedConflated stat is peeked object is unresolvable from off heap

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 5, 2016, 9:28 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52575/
> ---
> 
> (Updated Oct. 5, 2016, 9:28 p.m.)
> 
> 
> Review request for geode, nabarun nag and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> There is a scenario where the stats do not reflect an event being conflated.  
> After peeking the original object from the bucketRegionQueue, when we try to 
> resolve from off heap, if the resolved value is null, we just continue.  
> Instead we should behave similar to the bucketRegionQueue peek method, where 
> it increments the stat if the object itself is null.
> 
> Minor refactoring and changing of method visibility for testing purposes
> Removed some unused code
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueue.java
>  1a9b126 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/wan/parallel/ParallelGatewaySenderQueueJUnitTest.java
>  f1d4408 
> 
> Diff: https://reviews.apache.org/r/52575/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: First Apache Geode 1.0.0-incubating (GA) release...

[Dan Smith]

Switched to the dev list to discuss what to do with the nightly builds.

On Mon, Oct 10, 2016 at 5:13 PM, Anthony Baker  wrote:
> The ‘uploadArchives’ task publishes the maven artifacts into the snapshot 
> repo.  The Geode-Nightly jenkins job publishes the develop branch, currently 
> version 1.1.0-incubating:
>

Should we be publishing snapshots from the jenkins job for the release
branch as well? If we take too long to release, the 1.0 snapshots may
disappear entirely. In the meantime they are out of date. We'd have to
be careful to set releaseType=-SNAPSHOT in gradle.properties or on the
command line before doing that.

-Dan

Re: Review Request 52700: Add more tests to flaky category based on recent CI failures

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 10, 2016, 6:54 p.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52700/
> ---
> 
> (Updated Oct. 10, 2016, 6:54 p.m.)
> 
> 
> Review request for geode, Kirk Lund and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Add more tests to flaky category based on recent CI failures
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/FunctionServiceBase.java
>  5cd132781525210ff2869395978f15f2ec853c3d 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/ha/Bug48571DUnitTest.java
>  4bc7ecb7d1b97b80deb5e0ba549f1108946e34ea 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/HAInterestPart2DUnitTest.java
>  3fb15b5f5b387710076d512a060d2370bfe2319c 
>   
> geode-core/src/test/java/org/apache/geode/management/ClientHealthStatsDUnitTest.java
>  a62bb06863965a735e34b34ca4e94790657ee548 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/cli/commands/QueueCommandsDUnitTest.java
>  3a6a31a69b673438bf88e8933bd7be74b03d2cee 
>   
> geode-core/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationUsingDirDUnitTest.java
>  0683965fa9f38db59230532022fe0bbd7df3513c 
>   
> geode-core/src/test/java/org/apache/geode/security/SecurityClusterConfigDUnitTest.java
>  395d73e58fb984111c9d441a0ff57a1e1e900ea7 
>   
> geode-wan/src/test/java/org/apache/geode/internal/cache/wan/concurrent/ConcurrentParallelGatewaySenderDUnitTest.java
>  3451b51a16ec8a100d6e27096979dadf60cb5ed2 
>   
> geode-wan/src/test/java/org/apache/geode/internal/cache/wan/concurrent/ConcurrentWANPropagation_1_DUnitTest.java
>  e2461392e2b2e2d57b7d4fd78de19ca3de9abc38 
> 
> Diff: https://reviews.apache.org/r/52700/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Review Request 52699: while accessor is a diskstore for now, there's race that vm_0 only hosted 1 primary bucket.

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 10, 2016, 6:03 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52699/
> ---
> 
> (Updated Oct. 10, 2016, 6:03 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: geode-1956
> https://issues.apache.org/jira/browse/geode-1956
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Increase the number of buckets from 7 to 10 for now
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesPRBase.java
>  1de600d 
> 
> Diff: https://reviews.apache.org/r/52699/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Review Request 52698: GEODE-1972: Move Geode Hibernate module to a feature branch

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Oct. 10, 2016, 5:36 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52698/
> ---
> 
> (Updated Oct. 10, 2016, 5:36 p.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This removes hibernate from Geode
> 
> 
> Diffs
> -
> 
>   extensions/geode-modules-assembly/build.gradle f037aad 
>   extensions/geode-modules-hibernate/build.gradle 5169b04 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/EnumType.java
>  0a8218e 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/GemFireCache.java
>  134bbf6 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/GemFireCacheListener.java
>  0738f36 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/GemFireCacheProvider.java
>  2ccb5c0 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/GemFireQueryCacheFactory.java
>  fba1d9f 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/GemFireRegionFactory.java
>  088d0b1 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/Access.java
>  a14f7ac 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/ClientServerRegionFactoryDelegate.java
>  bbe3917 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/CollectionAccess.java
>  d921ade 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/EntityRegionWriter.java
>  d4f6f2f 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/EntityVersion.java
>  9851d29 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/EntityVersionImpl.java
>  ad866a6 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/EntityWrapper.java
>  a829de6 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/GemFireBaseRegion.java
>  022187a 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/GemFireCollectionRegion.java
>  5cb53ea 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/GemFireEntityRegion.java
>  0f514a4 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/GemFireQueryResultsRegion.java
>  28c9095 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/KeyWrapper.java
>  dc8793f 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/NonStrictReadWriteAccess.java
>  d6e9968 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/ReadOnlyAccess.java
>  e99210f 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/ReadWriteAccess.java
>  5597c97 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/RegionFactoryDelegate.java
>  1891528 
>   
> extensions/geode-modules-hibernate/src/main/java/org/apache/geode/modules/hibernate/internal/TransactionalAccess.java
>  c8ec670 
>   
> extensions/geode-modules-hibernate/src/test/java/org/apache/geode/modules/Event.java
>  39eec22 
>   
> extensions/geode-modules-hibernate/src/test/java/org/apache/geode/modules/HibernateJUnitTest.java
>  a9d6c64 
>   
> extensions/geode-modules-hibernate/src/test/java/org/apache/geode/modules/Owner.java
>  772f131 
>   
> extensions/geode-modules-hibernate/src/test/java/org/apache/geode/modules/Person.java
>  c98bb81 
>   
> extensions/geode-modules-hibernate/src/test/java/org/apache/geode/modules/SecondVMTest.java
>  cdc8e07 
>   extensions/geode-modules-hibernate/src/test/resources/log4j.properties 
> c136990 
>   
> extensions/geode-modules-hibernate/src/test/resources/org/apache/geode/modules/Event.hbm.xml
>  2473641 
>   
> extensions/geode-modules-hibernate/src/test/resources/org/apache/geode/modules/Person.hbm.xml
>  2105b1d 
>   gradle/sonar.gradle 33140d3 
>   settings.gradle 0b7002b 
> 
> Diff: https://reviews.apache.org/r/52698/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

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

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


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

Re: Hibernate module and Geode 1.0 ?

[Dan Smith]

+1 for moving it to a feature branch.

-Dan

On Wed, Oct 5, 2016 at 2:40 PM, Jason Huynh  wrote:
> Bumping to see if we have come to a decision on whether we want to move
> this to a feature branch and get rid of it for 1.0 or post 1.0, especially
> now that the 1.0 release branch has been cut
>
> On Fri, Sep 23, 2016 at 5:22 PM Anthony Baker  wrote:
>
> Likewise!  Geode provides an L2 cache for Hibernate.  That is, an
> application that is using Hibernate could plug in Geode for caching.
> Specifically, we implement Hibernate’s cache interfaces like CacheProvider,
> RegionFactory, etc.
>
> There are build-time dependencies on several hibernate jars
> (hibernate-annotations, hibernate-core, hibernate-commons-annotations).  No
> hibernate source code or jars are shipped with any release.
>
> Docs:
> http://geode.docs.pivotal.io/docs/tools_modules/hibernate_cache/chapter_overview.html
>
> Code:
> https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;a=tree;f=extensions/geode-modules-hibernate;h=be8b9355934f824b9d4565ec6bfaa5d17a117f45;hb=HEAD
>
> ~/working/apache-geode-1.0.0-incubating.M3$ unzip -l
> tools/Modules/Apache_Geode_Modules-1.0.0-incubating.M3-Hibernate.zip
> Archive:
> tools/Modules/Apache_Geode_Modules-1.0.0-incubating.M3-Hibernate.zip
>   Length Date   TimeName
>     
> 0  08-01-16 17:01   lib/
>114497  08-01-16 16:58   lib/geode-modules-1.0.0-incubating.M3.jar
> 56960  08-01-16 17:01
>  lib/geode-modules-hibernate-1.0.0-incubating.M3.jar
>     ---
>171457   3 files
>
> ~/working/apache-geode-1.0.0-incubating.M3$ jar tvf
> lib/geode-modules-hibernate-1.0.0-incubating.M3.jar
>  0 Mon Aug 01 17:01:40 PDT 2016 META-INF/
>139 Mon Aug 01 17:01:40 PDT 2016 META-INF/MANIFEST.MF
>  28210 Mon Jul 25 21:52:24 PDT 2016 META-INF/LICENSE
>584 Fri Jul 08 12:51:12 PDT 2016 META-INF/NOTICE
>  0 Mon Aug 01 17:01:40 PDT 2016 com/
>  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/
>  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/
>  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/modules/
>  0 Mon Aug 01 17:01:40 PDT 2016 com/gemstone/gemfire/modules/hibernate/
>   1210 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/EnumType.class
>   5707 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/GemFireCache.class
>   1700 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/GemFireCacheListener.class
>   7084 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/GemFireCacheProvider.class
>   1104 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/GemFireQueryCacheFactory.class
>   9529 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/GemFireRegionFactory.class
>  0 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/
>   1020 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/Access$1.class
>   9535 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/Access.class
>343 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/ClientServerRegionFactoryDelegate$1.class
>   1508 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/ClientServerRegionFactoryDelegate$LocatorHolder.class
>   9639 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/ClientServerRegionFactoryDelegate.class
>   9739 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/CollectionAccess.class
>   2409 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/EntityRegionWriter.class
>240 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/EntityVersion.class
>964 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/EntityVersionImpl.class
>   2446 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/EntityWrapper.class
>   5001 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/GemFireBaseRegion.class
>   2563 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/GemFireCollectionRegion.class
>   7702 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/GemFireEntityRegion.class
>   3058 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/GemFireQueryResultsRegion.class
>   2547 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/KeyWrapper.class
>   2911 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/NonStrictReadWriteAccess.class
>   1670 Mon Aug 01 17:01:40 PDT 2016
> com/gemstone/gemfire/modules/hibernate/internal/ReadOnlyAccess.class
>   1121 Mon Aug 01 17:01:40 PDT 2016
> 

Re: Assert usage in geode-core

[Dan Smith]

We need to get *all* of the optional dependencies out of the core.
That means anything marked optional in geode-core/build.gradle:
spring-shell, spring-webmvc, jansi, mx4j, etc. Mostly that is a matter
of moving gfsh, the admin REST API, etc. into separate subprojects
(GEODE-818).

Until we do that we're going to keep accidentally using these optional
dependencies in places in the core that aren't really optional at all.

As far as those Assert methods go, they appear to only be used in gfsh
and the admin rest API, and those bits are theoretically optional and
they already transitively depend on spring core. But the only way to
see that is to manually check. We need to get this management code out
of the core!

open> ./gradlew geode-core:findUsage -Djar.name=spring-core
Matches

org/apache/geode/management/internal/cli/shell/GfshExecutionStrategy.java
org/apache/geode/management/internal/cli/converters/DirConverter.java
org/apache/geode/management/internal/cli/util/CommentSkipHelper.java
org/apache/geode/management/internal/cli/multistep/CLIMultiStepHelper.java
org/apache/geode/management/internal/cli/remote/RemoteExecutionStrategy.java
org/apache/geode/management/internal/cli/parser/GfshMethodTarget.java
org/apache/geode/management/internal/web/util/ConvertUtils.java
org/apache/geode/management/internal/web/io/MultipartFileResourceAdapter.java
org/apache/geode/management/internal/web/http/converter/SerializableObjectHttpMessageConverter.java
org/apache/geode/management/internal/web/http/ClientHttpRequest.java

On Wed, Oct 5, 2016 at 4:56 PM, Anthony Baker <aba...@pivotal.io> wrote:
> Dan did some work on this:
>
> commit 71eb6bfbc429e7cc226671c99f682ec4fb31115d
> Author: Dan Smith <upthewatersp...@apache.org>
> Date:   Fri Sep 23 16:40:15 2016 -0700
>
> GEODE-1934: Removing spring-core dependencies from geode-core
>
> Remving the spring-core usage in geode-core classes that are not cli or
> web related. The CLI and web code needs to be split into separate
> projects. The rest of the geode-core should not depend on spring-core.
>
> I think Dan was fixing the case where a client application depends on 
> geode-core and hit a classpath issue due to an optional dependency on spring.
>
> Anthony
>
>
>> On Oct 5, 2016, at 4:45 PM, Jinmei Liao <jil...@pivotal.io> wrote:
>>
>> Is there a initiative to get spring-core dependency out of geode-core? The
>> only places we are using spring-core classes in geode-core are those Assert
>> statements like: Assert.isNull, Assert.notNull etc. Should we try to get
>> rid of those?
>>
>> --
>> Cheers
>>
>> Jinmei
>

Re: Podling Report Reminder - October 2016

[Dan Smith]

I added our report to https://wiki.apache.org/incubator/October2016,
it's ready for Mentor review and signoff.

Thanks!
-Dan

On Wed, Oct 5, 2016 at 9:29 AM, Anthony Baker <aba...@pivotal.io> wrote:
> Looks good!  I think the next step is uploading the report onto the wiki and 
> getting mentor signoff.
>
> Anthony
>
>> On Oct 3, 2016, at 4:08 PM, Dan Smith <dsm...@pivotal.io> wrote:
>>
>> Thanks Anthony and Swap! Updated draft:
>>
>> 
>> 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:
>>
>>  1. Expanding the community to include contributors and committers outside
>> of Pivotal.
>>  2. Establish a steady release cadence.
>>  3. Discuss graduation on the geode dev list.
>>
>> 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?
>>
>> - Karen Miller was added as a new committer and PPMC member
>> - 3 geode clubhouses on
>>   - Domain Driven Design & Reactive Programming w/ Apache Geode
>>   - What's New with Spring Data Geode
>>   - Events & Continuous Query
>> - 3 presentations involving geode at SpringOne:
>>  - Where Does Apache Geode Fit in CQRS Architectures?
>>  - Spring Data and In-Memory Data Management in Action
>>  - Design Tradeoffs in Distributed Systems - How Southwest Airlines Uses 
>> Geode
>> - A geode user group meeting in Tokyo
>>
>>
>> How has the project developed since the last report?
>> - We renamed packages from com.gemstone to org.apache to move us closer to
>>   graduation
>> - The geode documentation was donated to the project
>> - We had our third public release 1.0.0-incubating.M3
>> - We have cut a release branch and getting close to our final 1.0.0
>> release, using the apache package names
>>
>> Date of last release:
>>
>>  2016-08-23
>>
>> When were the last committers or PMC members elected?
>>
>>  Karen Miller 2016-07-18
>>
>> 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
>

Re: Review Request 52518: GEODE-1963: Add lucene xsd to website

[Dan Smith]

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


Ship it!




It's a little unfortunate to have two copies of these xsd files checked in. 
Long term I think we need to keep only one version of the xsds checked in and 
bundle them in both the source and the website.

- Dan Smith


On Oct. 4, 2016, 4:37 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52518/
> ---
> 
> (Updated Oct. 4, 2016, 4:37 p.m.)
> 
> 
> Review request for geode, Joey McAllister, William Markito, and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Lucene xsd should be added to the website.  This is checking in the xsd into 
> source control, after checking this in, I would generate/replace the website 
> content on the asf-site branch
> 
> 
> Diffs
> -
> 
>   geode-site/website/content/schema/cache/lucene-1.0.xsd PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/52518/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Podling Report Reminder - October 2016

[Dan Smith]

Thanks Anthony and Swap! Updated draft:


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:

  1. Expanding the community to include contributors and committers outside
of Pivotal.
  2. Establish a steady release cadence.
  3. Discuss graduation on the geode dev list.

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?

- Karen Miller was added as a new committer and PPMC member
- 3 geode clubhouses on
   - Domain Driven Design & Reactive Programming w/ Apache Geode
   - What's New with Spring Data Geode
   - Events & Continuous Query
- 3 presentations involving geode at SpringOne:
  - Where Does Apache Geode Fit in CQRS Architectures?
  - Spring Data and In-Memory Data Management in Action
  - Design Tradeoffs in Distributed Systems - How Southwest Airlines Uses Geode
- A geode user group meeting in Tokyo


How has the project developed since the last report?
 - We renamed packages from com.gemstone to org.apache to move us closer to
   graduation
 - The geode documentation was donated to the project
 - We had our third public release 1.0.0-incubating.M3
 - We have cut a release branch and getting close to our final 1.0.0
release, using the apache package names

Date of last release:

  2016-08-23

When were the last committers or PMC members elected?

  Karen Miller 2016-07-18

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

Re: Podling Report Reminder - October 2016

[Dan Smith]

Thanks John! Updated draft below.


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:

  1. Expanding the community to include contributors and committers outside
of
Pivotal.
  2. Establish a steady release cadence.
  3. Discuss graduation on the geode dev list.

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?

- Karen Miller was added as a new committer and PPMC member
- We held 3 geode clubhouses on
   - Domain Driven Design & Reactive Programming w/ Apache Geode
   - What's New with Spring Data Geode
   - Events & Continuous Query
- 3 presentations involving geode at SpringOne:
  - Where Does Apache Geode Fit in CQRS Architectures?
  - Spring Data and In-Memory Data Management in Action
  - Design Tradeoffs in Distributed Systems - How Southwest Airlines Uses
Geode

How has the project developed since the last report?
 - We renamed packages from com.gemstone to org.apache to move us closer to
   graduation
 - The geode documentation was donated to the project
 - We had our fourth public release 1.0.0-incubating.M3
 - We have cut a release branch and getting close to our final 1.0.0
release,
   using the apache package names

Date of last release:

  2016-08-23

When were the last committers or PMC members elected?

  Karen Miller 2016-07-18

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

Shepherd/Mentor notes:

Re: Podling Report Reminder - October 2016

[Dan Smith]

Here's a draft of our podling report for this quarter. Please review and
give your feedback.

Thanks!
-Dan


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:

  1. Expanding the community to include contributors and committers outside
of
Pivotal.
  2. Establish a steady release cadence.
  3. Discuss graduation on the geode dev list.

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?

- Karen Miller was added as a new committer and PPMC member
- We held 3 geode clubhouses on
   - Domain Driven Design & Reactive Programming w/ Apache Geode
   - What's New with Spring Data Geode
   - Events & Continuous Query
- Presentation on Geode at SpringOne: "Where Does Apache Geode Fit in CQRS
  Architectures?"

How has the project developed since the last report?
 - We renamed packages from com.gemstone to org.apache to move us closer to
   graduation
 - The geode documentation was donated to the project
 - We had our fourth public release 1.0.0-incubating.M3
 - We have cut a release branch and getting close to our final 1.0.0
release,
   using the apache package names

Date of last release:

  2016-08-23

When were the last committers or PMC members elected?

  Karen Miller 2016-07-18

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

Shepherd/Mentor notes:


On Mon, Oct 3, 2016 at 9:39 AM, Dan Smith <dsm...@pivotal.io> wrote:

> I can do this for this quarter.
>
> -Dan
>
> On Sun, Oct 2, 2016 at 6:13 AM, <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, 19 October 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, October 05).
>>
>> 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/October2016
>>
>> 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 52468: Add FlakyTest category to tests with open bugs

[Dan Smith]

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


Ship it!




I noticed you added additional ticket numbers to the same tests in a couple of 
places. Do we really need multiple tickets for the same test, or would it make 
sense to just close one of the tickets as a duplicate?

- Dan Smith


On Oct. 2, 2016, 12:07 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52468/
> ---
> 
> (Updated Oct. 2, 2016, 12:07 a.m.)
> 
> 
> Review request for geode.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Annotate test methods with FlakyTest category if there is an open
> bug for that test. This will improve the signal/noise ratio for
> unit/integration/distributed tests.  Flaky tests are still run
> as part of precheckin and flakyTest targets.
> 
> 
> Diffs
> -
> 
>   
> extensions/geode-modules-session/src/test/java/org/apache/geode/modules/session/internal/filter/SessionReplicationIntegrationJUnitTest.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/management/internal/configuration/SharedConfigurationEndToEndDUnitTest.java
>  PRE-CREATION 
>   
> geode-assembly/src/test/java/org/apache/geode/rest/internal/web/controllers/RestAPIsOnGroupsFunctionExecutionDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/ConnectionPoolDUnitTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/management/MemoryThresholdsOffHeapDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/CompiledInDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/QueryUsingFunctionContextDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/ConcurrentIndexOperationsOnOverflowRegionDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryCacheCloseDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/partitioned/PRQueryRegionCloseDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/DistributedSystemDUnitTest.java
>  PRE-CREATION 
>   geode-core/src/test/java/org/apache/geode/distributed/LocatorDUnitTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/LocatorLauncherTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/ServerLauncherTest.java 
> PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/SystemAdminDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/ConsoleDistributionManagerDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/distributed/internal/membership/MembershipJUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/FixedPRSinglehopDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/PartitionedRegionSingleHopDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/FunctionServiceBase.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRClientServerRegionFunctionExecutionDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRClientServerRegionFunctionExecutionFailoverDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRClientServerRegionFunctionExecutionSelectorNoSingleHopDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/execute/PRColocationDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/PersistentPartitionedRegionDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/fixed/FixedPartitioningDUnitTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/Bug36805DUnitTest.java
>  

Re: Geode docs: location of donated source files

[Dan Smith]

Sorry, yes, I meant a new geode-docs subdirectory.

-Dan

On Sat, Oct 1, 2016 at 5:12 PM, Anthony Baker  wrote:

> Did you mean a new top-level dir (e.g. geode-docs) or a subdir of
> geode-core?  Since the docs could cover multiple components I’m not sure it
> makes sense to put them under geode-core.
>
> Anthony
>
>
> >
> > I think we should just go ahead and create a feature branch off of the
> the
> > current geode develop and merge these changes in as a geode-core
> > subdirectory. We could start the work of cleaning up the build
> > instructions, etc. right away on that feature branch.
> >
> > -Dan
> >
>
>

Re: Podling Report Reminder - October 2016

[Dan Smith]

I can do this for this quarter.

-Dan

On Sun, Oct 2, 2016 at 6:13 AM,  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, 19 October 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, October 05).
>
> 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/October2016
>
> 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: Geode docs: location of donated source files

[Dan Smith]

Actually, it looks like the staging/docs-grant1 branch has *only* the docs
files, not anything else. If you are seeing directories like geode-core in
your local checkout of the branch, it's probably because you had build
artifacts in those directories and git left the directory around when you
switched branches. I don't see any geode-* directories when I get a clean
checkout or look at the branch on github
.

I think we should just go ahead and create a feature branch off of the the
current geode develop and merge these changes in as a geode-core
subdirectory. We could start the work of cleaning up the build
instructions, etc. right away on that feature branch.

-Dan

On Fri, Sep 30, 2016 at 4:03 PM, Dave Barnes  wrote:

> Please help me understand the source-control setup for the donated Geode
> docs.
> Per the announcement:
> > The donated source currently sits in a separate branch in the Geode
> repository named staging/docs-grant1
>
> I see when I check out the staging branch that the dozen or so user manual
> source directories are located at the topmost level of the repo,
> interspersed with source code directories. Another four individual files
> are placed at the top level, also, including a README.md that overwrites
> the README.md for the Geode code that I see when I'm working on the develop
> branch.
>
> I think it would be easier to find the files and distinguish them from
> source code if they were located in their own subdirectory, maybe
> 'geode-docs' for example. This would be helpful during the comment period,
> as well as later when the docs have been accepted as part of the main repo.
> - To what extent is the directory structure dictated by Apache precedent?
> - Can the locations be changed during the comment period?
> - If not, can the locations be changed after the comment period, before the
> branch is merged into the main repo?
>
> Thanks,
> Dave Barnes
>

Re: [ANNOUNCE] Donation of Geode documentation

[Dan Smith]

This is great!

Is this something we want to include in 1.0?

-Dan

On Thu, Sep 29, 2016 at 8:54 PM, Jared Stewart  wrote:

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

Review Request 52410: GEODE-1949: Adding geode-rebalancer to the binary distribution

[Dan Smith]

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

Review request for geode, Anthony Baker and Jason Huynh.


Repository: geode


Description
---

GEODE-1949: Adding geode-rebalancer to the binary distribution


Diffs
-

  geode-assembly/build.gradle c46c74af11798ed42cb69d6480069a69704a5932 

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


Testing
---


Thanks,

Dan Smith

Re: Previous versions dtds

[Dan Smith]

+1 for dropping the dtd up to 6.6. -1 for dropping 7.0/8.0, 8.1 xsd. I
think we should keep those for another release or two to make it easier for
people upgrading.

Is anyone actually using createTypesFromXml? If not, I would suggest
deprecating it.

-Dan

On Thu, Sep 29, 2016 at 2:33 PM, Jacob Barrett  wrote:

> The files MUST remain in the source otherwise the validating parser will
> have to download them from the website. This is VERY slow and only works if
> you have Internet access. The schema resolver first looks in the class path
> then to the web.
>
> -Jake
>
>
> On Thu, Sep 29, 2016 at 2:24 PM Anthony Baker  wrote:
>
> > Any active dtd's or schema’s should be hosted near to
> > http://geode.apache.org/schema/cache/.  If you follow the directions [1]
> > to update the website it’s not too hard.
> >
> > Can we remove the pivotal.io schema from source?
> >
> > ./geode-core/src/main/resources/META-INF/schemas/
> > schema.pivotal.io/gemfire/cache/cache-8.1.xsd
> >
> > We should upload the lucene scheme to the website also:
> > ./geode-lucene/src/main/resources/META-INF/schemas/
> > geode.apache.org/lucene/lucene-1.0.xsd
> >
> >
> > Anthony
> >
> > [1]
> > https://github.com/apache/incubator-geode/blob/develop/geode
> -site/website/README.md
> >
> >
> > > On Sep 29, 2016, at 2:15 PM, Darrel Schneider 
> > wrote:
> > >
> > > statisticsType.dtd is used
> > > by org.apache.geode.StatisticsTypeFactory.createTypesFromXml(Reader)
> > > See the javadocs on StatisticsTypeFactory for an example of how to use
> > it.
> > >
> > > On Thu, Sep 29, 2016 at 1:50 PM, Kirk Lund  wrote:
> > >
> > >> I'm actually unfamiliar with statisticsType.dtd:
> > >>
> > >> geode-core/src/main/resources/org/apache/geode/statisticsType.dtd
> > >>
> > >> I notice it still references GemStone and gemstone.com. Do we have
> > copies
> > >> of the dtds on geode.apache.org? Where should these dtds live online?
> > >>
> > >> Thanks,
> > >> Kirk
> > >>
> > >>
> > >> On Thu, Sep 29, 2016 at 9:37 AM, Hitesh Khamesra <
> > >> hitesh...@yahoo.com.invalid> wrote:
> > >>
> > >>> We have following dtds in geode source code. We were thinking to
> remove
> > >>> previous versions(1.0 to 6.6) of dtds.Please let us know if there is
> > any
> > >>> concern on  this.
> > >>>
> > >>> ./main/resources/org/apache/geode/admin/doc-files/ds4_0.dtd
> > >>> ./main/resources/org/apache/geode/admin/doc-files/ds5_0.dtd
> > >>> ./main/resources/org/apache/geode/admin/jmx/internal/doc-
> > >>> files/mbeans-descriptors.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache3_0.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache4_0.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache4_1.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_0.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_1.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_5.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_7.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache5_8.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_0.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_1.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_5.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache6_6.dtd
> > >>>
> > >>>
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache7_0.dtd
> > >>> ./main/resources/org/apache/geode/cache/doc-files/cache8_0.dtd
> > >>> ./main/resources/org/apache/geode/statisticsType.dtd
> > >>>
> > >>> Thanks.HItesh
> > >>>
> > >>>
> > >>
> >
> >
>

GEODE-1949 - Adding auto-balancer and spring-expression to geode-dependencies.jar

[Dan Smith]

Hi,

The geode-rebalancer jar is not currently shipped with the geode binary. I
think we should include as part of the binary distribution, and also
include it in geode-dependencies.jar so that it is on the classpath for the
server.

This won't require us to include any new dependencies in the lib directory,
but it does mean that we will need to include spring-expression in
geode-dependencies.jar (spring-expression was already in the lib
directory).  We're already including spring-core and spring-shell, are
there any issues with adding spring-expression as well?

-Dan

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

[Dan Smith]

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

Review request for geode, 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 52356: GEODE-1944: Index with method invocation in regionPath can throw exception when tombstones clean up during gii

[Dan Smith]

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


Fix it, then Ship it!





geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
 (line 1490)
<https://reviews.apache.org/r/52356/#comment218811>

Doesn't seem like it should catch an exception and ignore it here.


- Dan Smith


On Sept. 28, 2016, 4:41 p.m., Jason Huynh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52356/
> ---
> 
> (Updated Sept. 28, 2016, 4:41 p.m.)
> 
> 
> Review request for geode, nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The fix is to catch the EntryDestroyedException and execute a "remove" just 
> to force a removal from the index incase something/somehow got in there.  
> This specific problem would only occur on start up, during recovery from 
> disk, where tombstones have been reaped and we end up gii'ing and doing a 
> removeOldTombstones call.
> 
> Renamed and recategorized a few tests.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/CompactRangeIndex.java
>  c99da56 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/HashIndex.java
>  775daec 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexManager.java
>  4dcd1c3 
>   
> geode-core/src/main/java/org/apache/geode/cache/query/internal/index/IndexStore.java
>  c26ec48 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/dunit/CompactRangeIndexQueryDUnitTest.java
>  f8bae1b 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/AbstractIndexMaintenanceIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/CompactRangeIndexMaintenanceIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/CompactRangeIndexQueryIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/HashIndexJUnitTest.java
>  432199a 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/HashIndexMaintenanceIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/HashIndexQueryIntegrationTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/org/apache/geode/cache/query/internal/index/RangeIndexMaintenanceIntegrationTest.java
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/52356/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Jason Huynh
> 
>

Re: Review Request 52172: GEODE-1927: add support for old GemFire remote sites (WAN)

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Sept. 28, 2016, 4:08 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52172/
> ---
> 
> (Updated Sept. 28, 2016, 4:08 p.m.)
> 
> 
> Review request for geode, Hitesh Khamesra and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-1927
> https://issues.apache.org/jira/browse/GEODE-1927
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This adds a check in InternalDataSerializer for com.gemstone.gemfire packages 
> and transforms them to org.apache.geode.
> 
> I've also added a hook for translating org.apache.geode exceptions into 
> com.gemstone.gemfire exceptions.  We've decided to keep com.gemstone.gemfire 
> exceptions out of the Geode repository to avoid the confusion it would cause 
> to have an org.apache.geode implementation throw com.gemstone.gemfire 
> exceptions.
> 
> The latter change required changes to some tests using mocks to represent 
> ServerConnections.  These mocks were returning null from getClientVersion(), 
> causing NPEs in client/server code.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle a83b7a97016836b70a44d80c6a2221f4b4c8a5d9 
>   geode-core/src/main/java/org/apache/geode/CancelException.java 
> 94fd8b556dc04466b7fbae78bc6aaa48d3603c5d 
>   geode-core/src/main/java/org/apache/geode/DataSerializer.java 
> 8e2bad09adef9a6b4e7b5a5a71ff6b97fd515137 
>   geode-core/src/main/java/org/apache/geode/GemFireException.java 
> 142a97c9aa721cea82f7627a24da2517f3f97a24 
>   geode-core/src/main/java/org/apache/geode/cache/CacheException.java 
> 9b631a16b69bef63f9450b3c621764451ea743c4 
>   geode-core/src/main/java/org/apache/geode/cache/CacheRuntimeException.java 
> 9040596635c4ec6177f8e39183ab48025fa74658 
>   
> geode-core/src/main/java/org/apache/geode/cache/OperationAbortedException.java
>  340d1844b3d3827b6ff34c08a1ca814fb4c94be9 
>   geode-core/src/main/java/org/apache/geode/cache/RegionExistsException.java 
> 288dfe3c116ab7cd0cd3aec70473ad7c7ac918a8 
>   
> geode-core/src/main/java/org/apache/geode/internal/InternalDataSerializer.java
>  6e7aa55bd8a8b99c63f39965daa0222f42f64d30 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/BaseCommand.java
>  9a78772c466996f83383f4e63cb3d1d6654172a0 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/tier/sockets/OldClientSupportService.java
>  PRE-CREATION 
>   
> geode-core/src/main/java/org/apache/geode/internal/cache/wan/BatchException70.java
>  b795156c324f4a0a17a4a0009f5816dec46c8f4c 
>   geode-core/src/main/java/org/apache/geode/pdx/internal/PdxType.java 
> 2e5b19f8b4f2980bb16bf17249ea894fca0652b0 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/ContainsKey66Test.java
>  6728a377816e521a9419e8dd7576397f8548c14e 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/CreateRegionTest.java
>  389399191a3a69a1f591d029ecf3ea3981f845db 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/Destroy65Test.java
>  ed76cb6a965208b315ebb004cef39ea763d4b686 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/DestroyRegionTest.java
>  49a95a0bdae5f4fb51c0d6fcd8d5513805b45d26 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/DestroyTest.java
>  422733e4f5e958add74b4b7586bb123703776bc7 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/Get70Test.java
>  4b63a072370746e950ef3697358c7be7a125a213 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/InvalidateTest.java
>  2dcdd0413c292acd3a9ef40f9809f23f5e95ca29 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/Put61Test.java
>  c368ba89435303f498a212defdc2508426366093 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/Put65Test.java
>  830884c858ae3c6fd4121ed60343e4195b55d77a 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/PutTest.java
>  a9c3af43de1b5b23a958d22b577091e6ccf0bca5 
>   
> geode-core/src/test/java/org/apache/geode/internal/cache/tier/sockets/command/RequestTest.java
>  b6997bdef1b51e10780caf1eee6e3a7c46424f98 
>   
> geode-core/src/test/java/org

Review Request 52267: GEODE-1937: Making precheckin depend on running examples

[Dan Smith]

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

Review request for geode and William Markito.


Repository: geode


Description
---

Making precheckin depend on running examples

Also Setting a default GEODE_HOME to use when running example tests. Fixing
the example tests scripts to indicate that that are bash scripts as the
first line in the header.


Diffs
-

  build.gradle f7ce6bc49b87f15fa5b06d76fe4c24376c532933 
  geode-examples/build.gradle 1eadc3197c5345f90ca0d6f12e0c1f6594cbb68d 
  geode-examples/replicated/scripts/pidkiller.sh 
1a3eaf24a83da0692ca407383e0af4d3c57578a8 
  geode-examples/replicated/scripts/setEnv.sh 
60befc6bfe564fd5abfb1c47038ed1afeae74dac 
  geode-examples/replicated/scripts/startAll.sh 
f4ce413a27dd1ad136b364dfcfbe35a52c554ee9 
  geode-examples/replicated/scripts/stopAll.sh 
2a2c39b48ec469d8347529d3d471d49b34f29855 

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


Testing
---


Thanks,

Dan Smith

Re: Build failed in Jenkins: Geode-spark-connector #78

[Dan Smith]

I checked in a fix for the current dependencies on spring-core (thanks Kirk
and Udo). But we need to work on avoiding this issue in the future. Having
"optional" dependencies in the core seems like the main issue; a secondary
issue is that we don't have tests of geode-core that run with just the
non-optional geode-core dependencies available. Well, actually we do have
some tests in geode-examples, but apparently those aren't running as part
of precheckin! I filed GEODE-1937 for that.

-Dan

On Fri, Sep 23, 2016 at 8:15 PM, Kirk Lund <kl...@apache.org> wrote:

> org.apache.geode.internal.lang.StringUtils includes isEmpty(String)
>
> -Kirk
>
> On Friday, September 23, 2016, Udo Kohlmeyer <ukohlme...@pivotal.io>
> wrote:
>
> > I can easily fix this.
> >
> > Sure we have a utility lying around in the core that can handle
> > "String.isEmpty"
> >
> > --Udo
> >
> >
> > On 24/09/2016 9:56 AM, Anthony Baker wrote:
> >
> >> Yep, I’m seeing failures on any client app that doesn’t explicitly
> >> include spring as dependency.
> >>
> >> Exception in thread "main" java.lang.NoClassDefFoundError:
> >> org/springframework/util/StringUtils
> >> at org.apache.geode.internal.net.SSLConfigurationFactory.config
> >> ureSSLPropertiesFromSystemProperties(SSLConfigurationFactory.java:274)
> >> at org.apache.geode.internal.net.SSLConfigurationFactory.config
> >> ureSSLPropertiesFromSystemProperties(SSLConfigurationFactory.java:270)
> >> at org.apache.geode.internal.net.SSLConfigurationFactory.create
> >> SSLConfigForComponent(SSLConfigurationFactory.java:138)
> >> at org.apache.geode.internal.net.SSLConfigurationFactory.getSSL
> >> ConfigForComponent(SSLConfigurationFactory.java:67)
> >> at org.apache.geode.internal.net.SocketCreatorFactory.getSocket
> >> CreatorForComponent(SocketCreatorFactory.java:67)
> >> at org.apache.geode.distributed.internal.tcpserver.TcpClient. >> nit>(TcpClient.java:69)
> >> at org.apache.geode.cache.client.internal.AutoConnectionSourceI
> >> mpl.(AutoConnectionSourceImpl.java:114)
> >> at org.apache.geode.cache.client.internal.PoolImpl.getSourceImp
> >> l(PoolImpl.java:579)
> >> at org.apache.geode.cache.client.internal.PoolImpl.(PoolI
> >> mpl.java:219)
> >> at org.apache.geode.cache.client.internal.PoolImpl.create(PoolI
> >> mpl.java:132)
> >> at org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolF
> >> actoryImpl.java:319)
> >> at org.apache.geode.internal.cache.GemFireCacheImpl.determineDe
> >> faultPool(GemFireCacheImpl.java:2943)
> >> at org.apache.geode.internal.cache.GemFireCacheImpl.initializeD
> >> eclarativeCache(GemFireCacheImpl.java:1293)
> >> at org.apache.geode.internal.cache.GemFireCacheImpl.initialize(
> >> GemFireCacheImpl.java:1124)
> >> at org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate
> >> (GemFireCacheImpl.java:765)
> >> at org.apache.geode.internal.cache.GemFireCacheImpl.createClien
> >> t(GemFireCacheImpl.java:740)
> >> at org.apache.geode.cache.client.ClientCacheFactory.basicCreate
> >> (ClientCacheFactory.java:235)
> >> at org.apache.geode.cache.client.ClientCacheFactory.create(Clie
> >> ntCacheFactory.java:189)
> >> at HelloWorld.main(HelloWorld.java:25)
> >> Caused by: java.lang.ClassNotFoundException:
> >> org.springframework.util.StringUtils
> >> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> >> at sun.misc.Launcher$AppClassLoader.loadClass(
> Launcher.java:331)
> >> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> >> ... 19 more
> >>
> >> Anthony
> >>
> >>
> >> On Sep 23, 2016, at 4:34 PM, Dan Smith <dsm...@pivotal.io> wrote:
> >>>
> >>> I created GEODE-1934 for this. It looks like the problem is actually
> that
> >>> our dependencies for geode-core are messed up. spring-core is marked
> >>> optional, but we're using it in critical places like this
> >>> SSLConfigurationFactory.
> >>>
> >>> In my opinion we shouldn't depend on spring-core at all unless we're
> >>> actually going to use it for things other than StringUtils. I think
> we've
> >>> acciden

Re: Region Put errors out in Local Multi Server environment.

[Dan Smith]

Hi Jun,

Your perspective coming coming from the HDFS world makes sense with geode
as well. You configure the same partitioned region on all of your geode
nodes. Geode will then place partition your data across those nodes. Your
client will figure out where it should connect to get to the data correctly.

It is a bit confusing in this case that geode gives you the control to
shoot yourself in the foot by configuring your servers with different
regions. That type of configuration is potentially valid for some rare use
cases, but only if you also make use of server-groups to make sure your
client regions connect to the right servers. It's unfortunate that geode is
not enforcing that at configuration time.

See this page for a bit more about server-groups if you really need to go
that route. But generally you shouldn't need to do this:
http://geode.docs.pivotal.io/docs/topologies_and_comm/topology_concepts/how_server_discovery_works.html

-Dan

On Fri, Sep 23, 2016 at 5:29 PM, jun aoki <ja...@apache.org> wrote:

> I maybe making some stupid question but I'm from HDFS world where I don't
> have to care where data's physical location is. (You just connect to
> Namenode and you are good.) Bear with me.
>
> On Fri, Sep 23, 2016 at 5:26 PM, jun aoki <ja...@apache.org> wrote:
>
> > Hi Dan, thank you for sharing your insightful information.
> >
> > We only know how to get a cache from a locator as client cache.
> > e.g. clientCache = new ClientCacheFactory().addPoolLocator(LOCATOR_HOST,
> > LOCATOR_PORT).create();
> >
> > This way, when we try to create a PROXY region, we don't know which
> server
> > we are connecting to thus we don't know which region is available to the
> > client. (in Goutam's case, it seems it is actually connecting to server1
> > thus region1 is visible but not region2)
> >
> > Is there any way we can specify which server to connect so that under
> this
> > inconsistent configuration (each server holds different region) so that
> we
> > access to a target region appropriately?
> > Is this inconsistent configuration a valid configuration since it doesn't
> > error out at least, or it is a bad practice where Geode might not work as
> > we expect?
> >
> >
> >
> > On Fri, Sep 23, 2016 at 5:02 PM, Goutam Tadi <gt...@pivotal.io> wrote:
> >
> >> Thanks a lot Dan :-).
> >>
> >> Yeah, that was intentional.
> >> Your solution solves my problem.
> >>
> >> Thanks,
> >> Goutam Tadi.
> >>
> >> On Fri, Sep 23, 2016 at 4:58 PM Dan Smith <dsm...@pivotal.io> wrote:
> >>
> >> > Hi Goutam,
> >> >
> >> > It looks like you configured your two servers to have different
> regions.
> >> > Was that intentional? What's happening is that the client is
> connecting
> >> to
> >> > only one of the servers, which has one of your regions but not the
> >> other.
> >> >
> >> > Generally, when you configure gemfire servers, you should configure
> the
> >> > same regions on all servers. In this case I would put both of your
> >> regions
> >> > in the same cache.xml and use that for both servers. By default a
> geode
> >> > client will assume that all of your servers have the same regions and
> >> will
> >> > connect to one or more servers as it sees fit to minimize the number
> of
> >> > connections and reduce the number of network hops.
> >> >
> >> > If you really want to have servers that have different regions, you
> will
> >> > need to make use of the server-groups property on the server and
> create
> >> two
> >> > different pools on the client, using PoolFactory.setServerGroup to
> >> control
> >> > which group the client connects to. But I would say that's a less
> common
> >> > use case.
> >> >
> >> > -Dan
> >> >
> >> > On Fri, Sep 23, 2016 at 4:47 PM, Goutam Tadi <gt...@pivotal.io>
> wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > I was facing the *"Region not found"* exception when I do the
> >> following
> >> > on
> >> > > local machine (single Node) :
> >> > > And, I don't see the exception when I was trying to perform remote
> >> debug
> >> > > which introduced some time lapse. I tried to introduce some `sleep`
> ,
> >> but
> >> > > of no use
> >> > > Can you please help and let me know what I could be possibly doin

Review Request 52229: GEODE-1934: Removing spring-core dependencies from geode-core

[Dan Smith]

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

Review request for geode, Anthony Baker and Hitesh Khamesra.


Repository: geode


Description
---

Remving the spring-core usage in geode-core classes that are not cli or
web related. The CLI and web code needs to be split into separate
projects. The rest of the geode-core should not depend on spring-core.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/net/SSLConfigurationFactory.java
 4bea22bcd57079849bc1ed96b8d7fc9ca8a7ab0c 
  geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
bc1e896a2ed85260a9e9d95309735ea870d4761f 
  
geode-core/src/main/java/org/apache/geode/management/internal/configuration/domain/XmlEntity.java
 47f032e594abf090d68f5bb4d4a41b4442244875 
  geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java 
10a11d267754531bcd5bf116fa598fc0b3d5aad1 

Diff: https://reviews.apache.org/r/52229/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

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


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: Hibernate module and Geode 1.0 ?

[Dan Smith]

Geode provides an optional L2 cache for hibernate:

http://geode.docs.pivotal.io/docs/tools_modules/hibernate_cache/setting_up_the_module.html

Looking at the code, it looks like the geode-modules-hibernate is pulling
in hibernate-core as a compile dependency, but it's not being distributed
as part of the binary distribution.

-Dan

On Fri, Sep 23, 2016 at 4:54 PM, Roman Shaposhnik 
wrote:

> You've mentioned my trigger word ;-) Hibernate is licensed under LGPL
> so could you please specify how is Geode using it?
>
> Thanks,
> Roman.
>
> On Thu, Sep 22, 2016 at 3:15 PM, William Markito 
> wrote:
> > Folks,
> >
> > We're still building the Hibernate cache module [1] but it's compatible
> > only with a very old version (3.5) and given that the API has completely
> > changed and unless someone in the community wants to help getting this
> > module up-to-date with at least Hibernate 5.x I'd like propose to remove
> > the module from 1.0 / develop until we can work on updating that module.
> >
> > Given that it's already a separate module it shouldn't be that hard to be
> > removed.
> >
> > Thoughts ?
> >
> > [1]
> > http://geode.docs.pivotal.io/docs/tools_modules/hibernate_
> cache/chapter_overview.html
>

Re: Region Put errors out in Local Multi Server environment.

[Dan Smith]

Hi Goutam,

It looks like you configured your two servers to have different regions.
Was that intentional? What's happening is that the client is connecting to
only one of the servers, which has one of your regions but not the other.

Generally, when you configure gemfire servers, you should configure the
same regions on all servers. In this case I would put both of your regions
in the same cache.xml and use that for both servers. By default a geode
client will assume that all of your servers have the same regions and will
connect to one or more servers as it sees fit to minimize the number of
connections and reduce the number of network hops.

If you really want to have servers that have different regions, you will
need to make use of the server-groups property on the server and create two
different pools on the client, using PoolFactory.setServerGroup to control
which group the client connects to. But I would say that's a less common
use case.

-Dan

On Fri, Sep 23, 2016 at 4:47 PM, Goutam Tadi  wrote:

> Hi,
>
> I was facing the *"Region not found"* exception when I do the following on
> local machine (single Node) :
> And, I don't see the exception when I was trying to perform remote debug
> which introduced some time lapse. I tried to introduce some `sleep` , but
> of no use
> Can you please help and let me know what I could be possibly doing wrong?
>
> *Geode version: 1.0.0-incubating.M3*
>
> 1. *Start a locator : *
>
> start locator --name=testlocator --include-system-classpath
>
> ​
> 2. *Start two servers:*
>
> - start server --name=testserver1
> --cache-xml-file=SITMultiServerMultiRegion1.cache.xml
> --locators=localhost[10334] --server-port=30303
> --include-system-classpath
>
> - start server --name=testserver2
> --cache-xml-file=SITMultiServerMultiRegion2.cache.xml
> --locators=localhost[10334] --server-port=30304
> --include-system-classpath
>
> ​
> 3. *Java code to create ClientRegion and perform region.put()*
>
> private final static String LOCATOR_HOST = "localhost";
> private final static int LOCATOR_PORT = 10334;
>
> clientCache = new ClientCacheFactory().addPoolLocator(LOCATOR_HOST,
> LOCATOR_PORT).create();
>
> Region region1 = clientCache.
> createClientRegionFactory("PROXY").create(REGION1);
> assertNotNull(region1);
>
> Region region2 = clientCache.createClientRegionFactory("
> PROXY").create(REGION2);
> assertNotNull(region2);
>
> region1.put("key1", "region1"); // SUCCESSFUL
> region2.put("key2", "region2"); // ERROR OCCURRED.
>
> ​
> 4.* Cache xmls used:*
>
> *Cache-XML- 1*
>
> 
>
>   xmlns="http://schema.pivotal.io/gemfire/cache;
>  xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache
> http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd;
>  version="8.1">
>
>  
>
>  
>  
>  
>  
>
> 
>
> ​
>
>
> *Cache-XML- 2*
>
> 
>
>   xmlns="http://schema.pivotal.io/gemfire/cache;
>  xmlns:gpdb="http://schema.pivotal.io/gemfire/gpdb;
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>  xsi:schemaLocation="http://schema.pivotal.io/gemfire/cache
> http://schema.pivotal.io/gemfire/cache/cache-8.1.xsd;
>  version="8.1">
>
>  
>
>  
>  
>  
>  
>
> 
>
> ​
>
> 5. *StackTrace*:
>
>
> com.gemstone.gemfire.cache.client.ServerOperationException: remote
> server on gpdb(28401:loner):45180:20c75e59: : While performing a
> remote put
>
> at com.gemstone.gemfire.cache.client.internal.PutOp$
> PutOpImpl.processAck(PutOp.java:445)
>
> at com.gemstone.gemfire.cache.client.internal.PutOp$
> PutOpImpl.processResponse(PutOp.java:355)
>
> at com.gemstone.gemfire.cache.client.internal.PutOp$
> PutOpImpl.attemptReadResponse(PutOp.java:540)
>
> at com.gemstone.gemfire.cache.client.internal.AbstractOp.
> attempt(AbstractOp.java:378)
>
> at com.gemstone.gemfire.cache.client.internal.ConnectionImpl.execute(
> ConnectionImpl.java:274)
>
> at com.gemstone.gemfire.cache.client.internal.pooling.
> PooledConnection.execute(PooledConnection.java:328)
>
> at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.
> executeWithPossibleReAuthentication(OpExecutorImpl.java:937)
>
> at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(
> OpExecutorImpl.java:155)
>
> at com.gemstone.gemfire.cache.client.internal.OpExecutorImpl.execute(
> OpExecutorImpl.java:110)
>
> at com.gemstone.gemfire.cache.client.internal.PoolImpl.
> execute(PoolImpl.java:700)
>
> at com.gemstone.gemfire.cache.client.internal.PutOp.execute(
> PutOp.java:102)
>
> at com.gemstone.gemfire.cache.client.internal.ServerRegionProxy.put(
> ServerRegionProxy.java:175)
>
> at com.gemstone.gemfire.internal.cache.LocalRegion.serverPut(
> LocalRegion.java:3173)
>
> at com.gemstone.gemfire.internal.cache.LocalRegion.
> cacheWriteBeforePut(LocalRegion.java:3300)
>
> at com.gemstone.gemfire.internal.cache.ProxyRegionMap.basicPut(
> 

Re: Build failed in Jenkins: Geode-spark-connector #78

[Dan Smith]

I created GEODE-1934 for this. It looks like the problem is actually that
our dependencies for geode-core are messed up. spring-core is marked
optional, but we're using it in critical places like this
SSLConfigurationFactory.

In my opinion we shouldn't depend on spring-core at all unless we're
actually going to use it for things other than StringUtils. I think we've
accidentally introduced dependencies on it because the gfsh code in the
core is pulling in a bunch of spring libraries.

-Dan


On Fri, Sep 23, 2016 at 9:12 AM, Apache Jenkins Server <
jenk...@builds.apache.org> wrote:

> See 
>
> Changes:
>
> [hkhamesra] GEODE-37 In spark connector we call TcpClient static method to
> get the
>
> [klund] GEODE-1906: fix misspelling of Successfully
>
> [upthewaterspout] GEODE-1915: Prevent deadlock registering instantiators
> with gateways
>
> --
> [...truncated 1883 lines...]
> 16/09/23 16:11:05 INFO HttpFileServer: HTTP File server directory is
> /tmp/spark-f13dac55-087f-4379-aeed-616fbdc7ffac/httpd-
> 02c1fab9-faa0-47f4-b0f3-fd44383eeeb3
> 16/09/23 16:11:05 INFO HttpServer: Starting HTTP Server
> 16/09/23 16:11:05 INFO Utils: Successfully started service 'HTTP file
> server' on port 40135.
> 16/09/23 16:11:05 INFO SparkEnv: Registering OutputCommitCoordinator
> 16/09/23 16:11:10 WARN Utils: Service 'SparkUI' could not bind on port
> 4040. Attempting port 4041.
> 16/09/23 16:11:15 INFO Utils: Successfully started service 'SparkUI' on
> port 4041.
> 16/09/23 16:11:15 INFO SparkUI: Started SparkUI at http://localhost:4041
> 16/09/23 16:11:15 INFO Executor: Starting executor ID  on host
> localhost
> 16/09/23 16:11:15 INFO AkkaUtils: Connecting to HeartbeatReceiver:
> akka.tcp://sparkDriver@localhost:54872/user/HeartbeatReceiver
> 16/09/23 16:11:16 INFO NettyBlockTransferService: Server created on 41182
> 16/09/23 16:11:16 INFO BlockManagerMaster: Trying to register BlockManager
> 16/09/23 16:11:16 INFO BlockManagerMasterActor: Registering block manager
> localhost:41182 with 2.8 GB RAM, BlockManagerId(, localhost, 41182)
> 16/09/23 16:11:16 INFO BlockManagerMaster: Registered BlockManager
> === GeodeRunner: stop server 1.
> === GeodeRunner: stop server 2.
>  [0m[ [0minfo [0m]  [0m [32mRetrieveRegionIntegrationTest: [0m [0m
> ..
>
> === GeodeRunner: stop locator
> ...
> Successfully stop Geode locator at port 27662.
> === GeodeRunner: starting locator on port 23825
> === GeodeRunner: waiting for locator on port 23825
> === GeodeRunner: done waiting for locator on port 23825
> === GeodeRunner: starting server1 with clientPort 28993
> === GeodeRunner: starting server2 with clientPort 26318
> === GeodeRunner: starting server3 with clientPort 29777
> === GeodeRunner: starting server4 with clientPort 22946
> 
> Locator in
> /x1/jenkins/jenkins-slave/workspace/Geode-spark-connector/geode-spark-
> connector/geode-spark-connector/target/testgeode/locator on
> hemera.apache.org[23825] as locator is currently online.
> Process ID: 1860
> Uptime: 4 seconds
> GemFire Version: 1.0.0-incubating-SNAPSHOT
> Java Version: 1.8.0_66
> Log File: /x1/jenkins/jenkins-slave/workspace/Geode-spark-
> connector/geode-spark-connector/geode-spark-connector/target/testgeode/
> locator/locator.log
> JVM Arguments: -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.jmx-manager-http-port=29684 
> -Dgemfire.launcher.registerSignalHandlers=true
> -Djava.awt.headless=true -Dsun.rmi.dgc.server.
> gcInterval=9223372036854775806
> Class-Path: /x1/jenkins/jenkins-slave/workspace/Geode-spark-
> connector/geode-assembly/build/install/apache-geode/lib/geode-core-1.0.0-
> incubating-SNAPSHOT.jar:/x1/jenkins/jenkins-slave/workspace/Geode-spark-
> connector/geode-assembly/build/install/apache-geode/
> lib/geode-dependencies.jar
>
> Successfully connected to: JMX Manager [host=hemera.apache.org, port=1099]
>
> Cluster configuration service is up and running.
>
> 
> Server in /x1/jenkins/jenkins-slave/workspace/Geode-spark-
> connector/geode-spark-connector/geode-spark-connector/target/testgeode/server4
> on hemera.apache.org[22946] as server4 is currently online.
> Process ID: 2204
> Uptime: 8 seconds
> GemFire Version: 1.0.0-incubating-SNAPSHOT
> Java Version: 1.8.0_66
> Log File: /x1/jenkins/jenkins-slave/workspace/Geode-spark-
> connector/geode-spark-connector/geode-spark-connector/target/testgeode/
> server4/server4.log
> JVM Arguments: -Dgemfire.locators=localhost[23825] 
> -Dgemfire.use-cluster-configuration=true
> -Dgemfire.bind-address=localhost -Dgemfire.cache-xml-file=/x1/
> jenkins/jenkins-slave/workspace/Geode-spark-connector/geode-spark-
> connector/geode-spark-connector/src/it/resources/test-retrieve-regions.xml
> -Dgemfire.http-service-port=8080 -Dgemfire.start-dev-rest-api=false
> -XX:OnOutOfMemoryError=kill 

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

[Dan Smith]

> 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.
> 
> nabarun nag wrote:
> 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?

What you did looks good to me.


- Dan


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

[Dan Smith]

> 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

Your example above is in a while loop, so it actually is fetching the object on 
each iteration.


- Dan


---
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 52179: There's race condition that the AckReader thread got the read lock and waitng for ack, but the stopSender() kicks in

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Sept. 23, 2016, midnight, xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52179/
> ---
> 
> (Updated Sept. 23, 2016, midnight)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: geode-1894
> https://issues.apache.org/jira/browse/geode-1894
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> To resolve the race condition, we should double check if if Sender's 
> processor is stopped. If yes, then don't wait for ack
> 
> 
> Diffs
> -
> 
>   
> geode-wan/src/main/java/org/apache/geode/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
>  6beb0ee046d7e0cae5985b6430a390dd68f1351a 
> 
> Diff: https://reviews.apache.org/r/52179/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Review Request 52126: GEODE-1915: Prevent deadlock registering instantiators with gateways

[Dan Smith]

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

Review request for geode and Barry Oglesby.


Repository: geode


Description
---

Don't hold a lock while distributing instantiators. This prevents the
deadlock incoming registrations won't wait wait for registrations that
are being distributed.

This change might cause instantiators to be registered distributed in a
different order that they were registered in, but that shouldn't cause
any issues.


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/InternalInstantiator.java 
03987872308cb6a496770106029be08fdb346c71 
  geode-wan/src/test/java/org/apache/geode/internal/cache/wan/WANTestBase.java 
79648e19fdd07a165e6e118c9fbd0a209f470fe7 
  
geode-wan/src/test/java/org/apache/geode/internal/cache/wan/serial/SerialGatewaySenderOperationsDUnitTest.java
 2e796e71ef4811212a320240b98f35d9639b7e4e 

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


Testing
---


Thanks,

Dan Smith

Re: Error loading cluster config serialized prior to repackage

[Dan Smith]

I like your idea of having registered DataSwizzlers. Would registering a
DataSerializer for these classes work? It would be nice to just use the
extension mechanism that's already there.

-Dan

On Tue, Sep 20, 2016 at 1:29 PM, Bruce Schuchardt 
wrote:

> The repackage broke those two methods.  The oldPackage needs to replace
> "org.apache" with "com.gemstone".  It allows interaction with a locator
> from WAN sites and clients running GemFire.
>
> I'll fix that problem.
>
>
> Le 9/20/2016 à 11:53 AM, Kirk Lund a écrit :
>
>> If current develop attempts to read a cluster config that was persisted
>> prior to the repackage, our code now throws ClassNotFoundException. Turns
>> out Cluster Config is implemented by the
>> class org.apache.geode.management.internal.configuration.domain.Co
>> nfiguration
>> which is a DataSerializable. Unfortunately, a DataSerializableFixedID was
>> never added for this class, so the code resorts to using the fully
>> qualified class name.
>>
>> While brainstorming possible workarounds, we noticed a jgroups related
>> method in DataSerializer called swizzleClassNameForRead which is called
>> from readObject(DataInput):
>>
>>/**
>> * For backward compatibility we must swizzle the package of
>> * some classes that had to be moved when GemFire was open-
>> * sourced.  This preserves backward-compatibility.
>> *
>> * @param name the fully qualified class name
>> * @return the name of the class in this implementation
>> */
>>private static String swizzleClassNameForRead(String name) {
>>  String oldPackage = "org.apache.org.jgroups.stack.tcpserver";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>  String result = name;
>>  if (name.startsWith(oldPackage)) {
>>result = newPackage + name.substring(oldPackage.length());
>>  }
>>  return result;
>>}
>>
>> The package in red above never existed. I now have two questions: a) did
>> the repackage break this so that JGroups now need two swizzles (one for
>> the
>> jgroups upgrade and now a 2nd for the apache repackage)? b) can cluster
>> Configuration piggy back on this technique for handling the serialized
>> Configuration for cluster config?
>>
>> 1) jgroups upgrade
>>  String oldPackage = "com.gemstone.jgroups.stack.tcpserver";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>
>> 2) apache repackage for jgroups
>>  String oldPackage = "com.gemstone.gemfire.distribu
>> ted.internal.tcpserver
>> ";
>>  String newPackage = "org.apache.geode.distributed.
>> internal.tcpserver";
>>
>> 3) apache repackage for cluster config
>>  String oldPackage = "com.gemstone.gemfire.management.internal.
>> configuration.domain";
>>  String newPackage = "org.apache.geode.management.
>> internal.configuration.domain";
>>
>> Can anyone else think of something similar that might be broken? We could
>> scan the source code for DataSerializables that don't have a
>> corresponding DataSerializableFixedID.
>> Should we also scan for Serializable classes and try to determine if they
>> might be similarly persisted in a way that might break a feature?
>>
>> Is this the best way to handle this? Should we reorganize
>> swizzleClassNameForRead to be a series of registered DataSwizzlers?
>>
>> Thanks,
>> Kirk
>>
>>
>

Re: jvsd

[Dan Smith]

I don't think we should try to include jVSD in 1.0.0 at this point, because
it introduces dependencies that might make the 1.0.0 release more
complicated such as the MultiAxisChartFX dependency. But I think the should
try to get it to develop sooner rather than later to make it easier for
people to get jVSD and play with it.

-Dan

Re: Review Request 52076: GEODE-1511: Remove test dependencies from pom file

[Dan Smith]

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



I don't think having this special logic for slf4j-impl is necessary because 
slf4j-impl already marked optional. It was *not* optional in M3, because of 
GEODE-1811. So I think this bug was already fixed by GEODE-1811.

As far as including/excluding test dependencies, I don't think it really 
matters since they have no effect. But maybe we should just stick with the 
default behavior of the gradle plugin?

- Dan Smith


On Sept. 20, 2016, 3:49 a.m., Anthony Baker wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/52076/
> ---
> 
> (Updated Sept. 20, 2016, 3:49 a.m.)
> 
> 
> Review request for geode, Dick Cavender, Jens Deppe, Mark Bretl, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Remove test dependecies from pom as they are not needed for geode
> applications. Also removes the log4j-slf4j-impl logging bridge.
> This reduces the possibility for conflicts on the application
> classpath.  The bridge jar is still present on the server
> classpath.
> 
> 
> Diffs
> -
> 
>   gradle/publish.gradle 8a579c2f166d42d980fec9bf01a2ecb2364ddacf 
> 
> Diff: https://reviews.apache.org/r/52076/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Anthony Baker
> 
>

Re: Gfsh Command enhancement - show missing-disk-stores

[Dan Smith]

I think it should be a single command because the user is trying to
diagnose the same problem - what persistent data is missing that is
preventing system recovery? I'm not sure what the best name of the command
is.

-Dan

On Fri, Sep 9, 2016 at 1:40 PM, Kenneth Howe  wrote:

> GEODE-1128  requests
> the addition of missing colocated region information to the gfsh show
> missing-disk-stores command. This is of course doable, however with
> additional information not directly related to disk stores, the command
> name would be misleading. You may have missing colocated regions without
> missing disk stores, or the converse, missing stores without missing
> regions.
>
> So my question is: Should the command be renamed to better indicate the
> types of information reported? While working on this Jira, I have been
> using the new command name ‘show persistent-recovery-failures’. (Please
> suggest a better name!)
>
> Alternatives to renaming the command are
> 1) Do nothing with the command name. Add the missing colocated region
> information, but leave the command name as is.
> 2) Add a new command with both missing disk stores and missing colocated
> regions, and leave the existing missing-disk-stores command as is.
>
> Looking for a consensus on the best approach.
>
> Thanks,
> Ken Howe
>

Re: Review Request 51741: [GEODE-1817] Prepare for 'release quality' publishing

[Dan Smith]

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



The changes look good, but I don't think we want to disable release signing by 
default. Geode releases should be signed with gpg.

- Dan Smith


On Sept. 8, 2016, 7:35 p.m., Jens Deppe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51741/
> ---
> 
> (Updated Sept. 8, 2016, 7:35 p.m.)
> 
> 
> Review request for geode, Anthony Baker and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This also disables default archive signing which requires GPG keys
> 
> 
> Diffs
> -
> 
>   build.gradle e112eb77847371f730ba72febfa350bfe9466832 
>   gradle.properties 06855c7a3782cb83cce9731460d3197749de42f3 
>   gradle/publish.gradle 2258da6537b69afad0c3188d06f91da9fd8c08c3 
> 
> Diff: https://reviews.apache.org/r/51741/diff/
> 
> 
> Testing
> ---
> 
> Local building. The changes come into effect when using 'uploadArchives'.
> 
> 
> Thanks,
> 
> Jens Deppe
> 
>

Re: Nightly Build still failing with BindExceptions

[Dan Smith]

I suspect many of these BindExceptions are caused by the test itself trying
to use the same port twice, rather than something else on the box grabbing
a port.

I do think the long term solution is to get rid of AvailablePort. But maybe
in the short term we could change it to not pick a random number, but
instead always start from the same point? That way if there are bugs in the
tests they would fail every time.

-Dan

On Wed, Sep 7, 2016 at 6:17 AM, Jens Deppe  wrote:

> We're already using that plugin to run the distributedTest task. We have a
> story to also implement that for flaky tests.
>
> --Jens
>
> On Tue, Sep 6, 2016 at 9:16 PM, Sai Boorlagadda  >
> wrote:
>
> > +1 for dockerized tests.
> >
> > Most of the CI failures due to state left over are not easily
> reproducible.
> > I prefer spending time eliminating these failures and may be dockerized
> > tests would be the way to go.
> >
> > Sai
> >
> > On Tue, Sep 6, 2016 at 5:44 PM, Swapnil Bawaskar 
> > wrote:
> >
> > > To make sure this is not a problem again, how about running the tests
> in
> > > their own container using something like gradle-dockerized-test-plugin[
> > 1]?
> > > If each of our test is run in its own container, we will be able to
> > address
> > > the BindAddress as well as "state left by previous test" issue. Sure
> this
> > > will take longer to complete the tests, but we only do a nightly build.
> > We
> > > could also run our tests in parallel in different containers to
> speed-up
> > > our build. We could also go one step further in getting a clean slate
> on
> > > "CI failure" issues. My main argument for doing this are:
> > > 1. We have 190 issues that are marked as "ci" failures [2].
> > > 2. That a lot of CI failures are due to state left behind by previous
> > > tests. (26 are just bind exceptions[3])
> > >
> > > Fixing 190 test issues is definitely going to slow us down from adding
> > > features to Geode, so getting a clean slate will allow us to narrow
> down
> > CI
> > > failures to race condition in test (or product).
> > >
> > > If we think this is a good idea, then we could check with ASF infra to
> > see
> > > if docker can be setup on jenkins slaves.
> > >
> > > [1] https://github.com/pedjak/gradle-dockerized-test-plugin
> > > [2]
> > > https://issues.apache.org/jira/browse/GEODE-1778?jql=
> > > project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%
> > > 22In%20Progress%22%2C%20Reopened)%20AND%20labels%20%3D%20ci
> > > [3]
> > > https://issues.apache.org/jira/browse/GEODE-973?jql=
> > > project%20%3D%20GEODE%20AND%20status%20in%20(Open%2C%20%
> > > 22In%20Progress%22%2C%20Reopened)%20AND%20text%20~%
> 20%22BindException%22
> > >
> > > On Tue, Sep 6, 2016 at 3:01 PM, Kirk Lund  wrote:
> > >
> > > > No wonder that test is intermittently failing then. I didn't think we
> > had
> > > > any tests with hard-coded ports. I filed GEODE-1863 and Darrel picked
> > it
> > > > up.
> > > >
> > > > -Kirk
> > > >
> > > > On Tue, Sep 6, 2016 at 9:30 AM, Bruce Schuchardt <
> > bschucha...@pivotal.io
> > > >
> > > > wrote:
> > > >
> > > > > This test is not using AvailablePort.  There are two test cases in
> > this
> > > > > class that alway use port .
> > > > >
> > > > >
> > > > > Le 9/6/2016 à 8:00 AM, Anthony Baker a écrit :
> > > > >
> > > > >> How could we fix AvailablePort so we don’t try to use in-use
> ports?
> > > > >>
> > > > >> Anthony
> > > > >>
> > > > >> On Sep 3, 2016, at 10:29 PM, Kirk Lund  wrote:
> > > > >>>
> > > > >>> We're still hitting BindExceptions in the nightly build, so I'll
> go
> > > > ahead
> > > > >>> and propose this again: any test that uses AvailablePort to find
> a
> > > > random
> > > > >>> port could be altered to automatically Retry if it encounters and
> > > fails
> > > > >>> because of java.net.BindException. Opinions?
> > > > >>>
> > > > >>> -Kirk
> > > > >>>
> > > > >>> :geode-core:integrationTest
> > > > >>>
> > > > >>> com.gemstone.gemfire.internal.cache.DiskRegionJUnitTest >
> > > > >>> testBridgeServerRunningInSynchPersistOnlyForIOExceptionCase
> FAILED
> > > > >>> java.net.BindException: Failed to create server socket on
> > > > >>> null[5,555]
> > > > >>> at com.gemstone.gemfire.internal.
> > > > SocketCreator.createServerSock
> > > > >>> et(
> > > > >>> SocketCreator.java:814)
> > > > >>> at com.gemstone.gemfire.internal.
> > > > SocketCreator.createServerSock
> > > > >>> et(
> > > > >>> SocketCreator.java:774)
> > > > >>> at com.gemstone.gemfire.internal.
> > > > SocketCreator.createServerSock
> > > > >>> et(
> > > > >>> SocketCreator.java:738)
> > > > >>> at com.gemstone.gemfire.internal.cache.tier.sockets.
> > > > >>> AcceptorImpl.(AcceptorImpl.java:470)
> > > > >>> at com.gemstone.gemfire.internal.
> > > cache.CacheServerImpl.start(
> > > > >>> CacheServerImpl.java:323)
> > > > >>> at 

Re: Review Request 51696: GEODE-1777 CI failure: RestAPIsOnMembersFunctionExecutionDUnitTest.testFunctionExecutionEOnSelectedMembers[

[Dan Smith]

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


Ship it!




We might also want to change the settings in gradle/test.gradle for the 
constroller VM. See line "jvmArgs = ['-XX:+HeapDumpOnOutOfMemoryError', '-ea']" 
That affects all tests - unit tests, integration tests, and distributed tests 
though.

- Dan Smith


On Sept. 7, 2016, 4:25 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51696/
> ---
> 
> (Updated Sept. 7, 2016, 4:25 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Hitesh Khamesra, Udo Kohlmeyer, and 
> Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Looking through our distributedTest output I see a large number of full GCs 
> initiated by Metaspace cleanup.  Some of these GCs are taking as long as 70 
> seconds and cause nodes to be kicked out of the distributed system.  For Java 
> 8 it's recommended that you estimate requirements for Metaspace and set 
> XXMetaspaceSize to avoid these full GCs.  Our REST tests seem to need nearly 
> half a gigabyte of metaspace so I've set it accordingly.  An AWS precheckin 
> run with this change showed only one GC initiated by metaspace management, in 
> the geode-web distributedTest suite lasting 1/2 second.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/test/dunit/standalone/ProcessManager.java
>  f938c1a88cfec459efe4c87b8be41a6fa5c291e4 
> 
> Diff: https://reviews.apache.org/r/51696/diff/
> 
> 
> Testing
> ---
> 
> precheckin
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

Re: Review Request 51728: GEODE-1570: upgrade spring libraries and fix tests

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Sept. 8, 2016, 3:45 p.m., Jinmei Liao wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51728/
> ---
> 
> (Updated Sept. 8, 2016, 3:45 p.m.)
> 
> 
> Review request for geode, Kevin Duling, Kirk Lund, Udo Kohlmeyer, and Dan 
> Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> * updated the spring framework libraries
> * updated the spring security libraries and related upgrades
> * fixed the tests and uitests
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/RestInterfaceJUnitTest.java
>  8246671a7e70267d64e354ad3ce43c1afb56f7c3 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/RestSecurityDUnitTest.java
>  847ca7675da6c0490e0fdc9ceacda89c4a1ec7e8 
>   geode-assembly/src/test/resources/expected_jars.txt 
> 939464a92a3f1846b8fb9b9d1faa75dad5133289 
>   geode-core/build.gradle ea1fce20f45b523e98b62b7569275c0079313a5a 
>   
> geode-core/src/test/java/com/gemstone/gemfire/management/internal/cli/shell/GfshInitFileJUnitTest.java
>  529336f813cfd6a0f2b227281084a805f34c1729 
>   geode-pulse/build.gradle e53a698700f0de62088b3ac50cb96d4841315124 
>   
> geode-pulse/src/main/java/com/vmware/gemfire/tools/pulse/internal/security/GemFireAuthentication.java
>  391ad39d22dfe37ee056c7cdeb6d2bf6554206ae 
>   
> geode-pulse/src/main/java/com/vmware/gemfire/tools/pulse/internal/security/GemFireAuthenticationProvider.java
>  2d7d6068337e95a3bcc6acc1aa211bf8c6da19d1 
>   
> geode-pulse/src/main/java/com/vmware/gemfire/tools/pulse/internal/service/MemberGatewayHubService.java
>  dd84b75c5742b3457d82a1a101521948cc8508f2 
>   geode-pulse/src/main/webapp/Login.html 
> f22490f4df098c0b12dadeefcb1855a51efc6281 
>   geode-pulse/src/main/webapp/WEB-INF/mvc-dispatcher-servlet.xml 
> 60edb18ba615b69e6fc04fde35bf829dcfef34db 
>   geode-pulse/src/main/webapp/WEB-INF/spring-security.xml 
> b14d03d2a27f061c37af8a644610156fc4b651a9 
>   
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAuthTest.java
>  65cd47fb111e765cc515466728221ef6607221ca 
>   
> geode-pulse/src/test/java/com/vmware/gemfire/tools/pulse/tests/PulseAutomatedTest.java
>  299a343bd7258c97a5ce8b63ae5e5e35ae242142 
>   
> geode-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/util/JSONUtils.java
>  cb9b39df46701903a1c5c0bf78d7e728083a27a3 
>   
> geode-web-api/src/main/java/com/gemstone/gemfire/rest/internal/web/util/JsonWriter.java
>  a0ff676a9eeb64cf1c8151a60a20633a38ef80f1 
>   geode-web-api/src/main/webapp/WEB-INF/geode-servlet.xml 
> e96acb0d2805abce804b04be678374054652f671 
>   geode-web/src/main/webapp/WEB-INF/geode-mgmt-servlet.xml 
> ce659336c0cad8ce8e75de50ee69856259c69af2 
>   gradle/dependency-resolution.gradle 
> 91d1755848ba9ce23fab3190555c2906bcffd97b 
>   gradle/dependency-versions.properties 
> a19520cb6f75bd63136d99ff62efd2b9d5f45643 
> 
> Diff: https://reviews.apache.org/r/51728/diff/
> 
> 
> Testing
> ---
> 
> precheckin and uitests and pulse
> 
> 
> Thanks,
> 
> Jinmei Liao
> 
>

Re: Build failed in Jenkins: Geode-spark-connector #68

[Dan Smith]

Looks like our scala build is looking for a snapshot geode version that
doesn't exist any more. I'll fix it.

-Dan

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

> See 
>
> --
> [...truncated 833 lines...]
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#main;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#actions;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#classpath;0.13.6 ...
> [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-lang#scala-compiler;2.10.4
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-lang#scala-reflect;2.10.4
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#launcher-interface;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#interface;0.13.6 ...
> [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#io;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#control;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#completion;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#collections;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving jline#jline;2.11 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#api;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving 
> org.scala-sbt#compiler-integration;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving 
> org.scala-sbt#incremental-compiler;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#logging;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#process;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#relation;0.13.6 ...
> [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#compile;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#persist;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving 
> org.scala-tools.sbinary#sbinary_2.10;0.4.2
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#classfile;0.13.6 ...
> [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving 
> org.scala-sbt#compiler-ivy-integration;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#ivy;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#cross;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt.ivy#ivy;2.3.0-sbt-
> 14d4d23e25f354cd296c73bfff405544434d5f80 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving com.jcraft#jsch;0.1.46 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#run;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#task-system;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#tasks;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#tracking;0.13.6 ...
> [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#cache;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#testing;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#test-agent;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#test-interface;1.0
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#main-settings;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#apply-macro;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#command;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#logic;0.13.6 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#compiler-interface;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#precompiled-2_8_2;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#precompiled-2_9_2;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-sbt#precompiled-2_9_3;0.13.6
> ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.scala-lang#jline;2.10.4 ... [0m
>
>  M [2K [0m[ [0minfo [0m]  [0mResolving org.fusesource.jansi#jansi;1.4 ...
> [0m
>  [0m[ [0minfo [0m]  [0mdownloading https://repo1.maven.org/
> maven2/org/scalastyle/scalastyle-sbt-plugin_2.10_0.
> 13/0.6.0/scalastyle-sbt-plugin-0.6.0.jar ... [0m
>  [0m[ [0minfo [0m]  [0m [SUCCESSFUL ] org.scalastyle#scalastyle-sbt-
> plugin;0.6.0!scalastyle-sbt-plugin.jar (17ms) [0m
>  [0m[ [0minfo [0m]  [0mdownloading https://repo.scala-sbt.org/
> scalasbt/sbt-plugin-releases/org.scoverage/sbt-scoverage/
> scala_2.10/sbt_0.13/1.0.4/jars/sbt-scoverage.jar ... [0m
>  [0m[ [0minfo [0m]  [0m [SUCCESSFUL ] 
> org.scoverage#sbt-scoverage;1.0.4!sbt-scoverage.jar
> (1482ms) [0m
>  [0m[ [0minfo [0m]  [0mdownloading https://repo1.maven.org/
> maven2/org/scalastyle/scalastyle_2.10/0.6.0/scalastyle_2.10-0.6.0.jar ...
> [0m
>  [0m[ [0minfo [0m]  [0m [SUCCESSFUL ] 
> org.scalastyle#scalastyle_2.10;0.6.0!scalastyle_2.10.jar
> 

Re: Review Request 51585: let getId() return unique name

[Dan Smith]

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



I think the ID needs to include something indicating that this profile is for 
lucene, rather than some other cache service. Maybe the fully qualified name of 
the class? I don't think adding the region really makes a difference, because 
the profile is already region specific.

- Dan Smith


On Sept. 1, 2016, 10:04 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51585/
> ---
> 
> (Updated Sept. 1, 2016, 10:04 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-11
> https://issues.apache.org/jira/browse/GEODE-11
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Should return the internal unique name of the index for each lucene index.
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexCreationProfile.java
>  720d20d 
> 
> Diff: https://reviews.apache.org/r/51585/diff/
> 
> 
> Testing
> ---
> 
> geode-lucene:precheckin
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Review Request 51567: should save the reference of serverlocation in case it was destroyed by another thread

[Dan Smith]

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


Ship it!




Ship It!

- Dan Smith


On Aug. 31, 2016, 11:49 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51567/
> ---
> 
> (Updated Aug. 31, 2016, 11:49 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-1833
> https://issues.apache.org/jira/browse/GEODE-1833
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> The code called sender.getServerLocation() every time.
> 
> If we only check if it's null once, then we should save the reference, 
> otherwise, we have to check the null after each call of 
> sender.getServerLocation().
> 
> 
> Diffs
> -
> 
>   
> geode-wan/src/main/java/com/gemstone/gemfire/internal/cache/wan/GatewaySenderEventRemoteDispatcher.java
>  2625ad2 
> 
> Diff: https://reviews.apache.org/r/51567/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

Re: Review Request 51547: refactor the luceneIndex and repoManager to use index reference, and add FSDirectory support

[Dan Smith]

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


Fix it, then Ship it!





geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexRecoveryHAIntegrationTest.java
 (line 65)
<https://reviews.apache.org/r/51547/#comment214680>

Remove commented out code



geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexRecoveryHAIntegrationTest.java
 (line 95)
<https://reviews.apache.org/r/51547/#comment214679>

Remove commented out code


- Dan Smith


On Aug. 30, 2016, 11:52 p.m., xiaojian zhou wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/51547/
> ---
> 
> (Updated Aug. 30, 2016, 11:52 p.m.)
> 
> 
> Review request for geode and Dan Smith.
> 
> 
> Bugs: GEODE-11
> https://issues.apache.org/jira/browse/GEODE-11
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> add FSDirectory support
> 
> also refactor LuceneIndexImpl, LuceneIndexForPartitionedReigon, 
> PartitionedRepositoryManager to use index reference
> 
> 
> Diffs
> -
> 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/AbstractPartitionedRepositoryManager.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/IndexRepositoryFactory.java
>  ae4b88b 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexFactory.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegion.java
>  af05e7d 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexImpl.java
>  ff31c49 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneRawIndex.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneRawIndexFactory.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/LuceneServiceImpl.java
>  82aee8b 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManager.java
>  3cc713b 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/RawIndexRepositoryFactory.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/RawLuceneRepositoryManager.java
>  PRE-CREATION 
>   
> geode-lucene/src/main/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImpl.java
>  0b70542 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneIndexCreationIntegrationTest.java
>  0974bf0 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/LuceneQueriesPRBase.java
>  1de600d 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexForPartitionedRegionTest.java
>  6f38ff4 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/LuceneIndexRecoveryHAIntegrationTest.java
>  67f318b 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/PartitionedRepositoryManagerJUnitTest.java
>  2221a6d 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/RawLuceneRepositoryManagerJUnitTest.java
>  PRE-CREATION 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/distributed/DistributedScoringJUnitTest.java
>  1f1d2c9 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImplJUnitTest.java
>  cd67413 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/internal/repository/IndexRepositoryImplPerformanceTest.java
>  3155aaf 
>   
> geode-lucene/src/test/java/com/gemstone/gemfire/cache/lucene/test/IndexRepositorySpy.java
>  0b66f55 
> 
> Diff: https://reviews.apache.org/r/51547/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>

M3 vs. M2 dependencies

[Dan Smith]

I was comparing our required dependencies of geode-core for the M3 vs. M2
release (Anything with compile or runtime scope in the pom and not marked
optional). It looks like they are pretty similar, with the below
differences.

Removed in M3:
  geode-joptsimple

Added in M3:
  shiro-core
  commons-beanutils (required by shiro)
  jopt-simple

Should any of these new additions be marked optional, or maybe have the
dependent code moved out of core?

All required runtime dependencies of geode-core:
  antlr:antlr:2.7.7
  com.fasterxml.jackson.core:jackson-annotations:2.2.0
  com.fasterxml.jackson.core:jackson-core:2.2.0
  com.fasterxml.jackson.core:jackson-databind:2.2.0
  com.github.stephenc.findbugs:findbugs-annotations:1.3.9-1
  commons-beanutils:commons-beanutils:1.8.3
  commons-io:commons-io:2.3
  commons-lang:commons-lang:2.5
  commons-logging:commons-logging:1.2
  it.unimi.dsi:fastutil:7.0.2
  javax.resource:javax.resource-api:1.7
  javax.transaction:javax.transaction-api:1.2
  net.java.dev.jna:jna:4.0.0
  net.sf.jopt-simple:jopt-simple:5.0.1
  org.apache.geode:geode-common:1.0.0-incubating.M3
  org.apache.geode:geode-json:1.0.0-incubating.M3
  org.apache.logging.log4j:log4j-api:2.6.1
  org.apache.logging.log4j:log4j-core:2.6.1
  org.apache.logging.log4j:log4j-jcl:2.6.1
  org.apache.logging.log4j:log4j-jul:2.6.1
  org.apache.logging.log4j:log4j-slf4j-impl:2.6.1
  org.apache.shiro:shiro-core:1.2.4
  org.fusesource.jansi:jansi:1.8
  org.jgroups:jgroups:3.6.10.Final
  org.slf4j:slf4j-api:1.7.21

-Dan

Review Request 51308: GEODE-1811: Marking runtime dependencies as optional in the pom

[Dan Smith]

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

Review request for geode, Anthony Baker and Mark Bretl.


Repository: geode


Description
---

We had certain runtime dependencies marked as optional in
geode-core/build.gradle. However, we were only looking for the optional
flag on compile dependencies, so the runtime dependencies were not
marked as optional in the generated pom file.


Diffs
-

  gradle/publish.gradle 768fce43459eb4a0397f055100aac481d8ed89ae 

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


Testing
---


Thanks,

Dan Smith

Re: git commit messages

[Dan Smith]

Yeah, 50 chars seems a bit short. I think I've been aiming for 72
personally.

-Dan

On Wed, Aug 17, 2016 at 4:37 PM, Kirk Lund  wrote:

> Some examples from feature/GEODE-1781-02 which are my latest unmerged
> commits...
>
> 1) 1st line is 62 chars. To shorten to 50: "GEODE-1799: fix javadocs on
> CacheServerStats" or "GEODE-1799: change javadocs from Bridge to Cache"
>
> commit 0a07db189c8b928976ed6554499f15b6a64e1633
> Author: Kirk Lund 
> Date:   Wed Aug 17 16:27:52 2016 -0700
>
> GEODE-1799: change javadocs from Bridge Server to Cache Server
>
> 2) 1st line is 80 chars. To shorten to 50: "GEODE-1781: exclude class from
> AnaylzeSerializableJUnitTest"
>
> commit 55c5df5e4cd6228be1617fb1e92d8d955a703b08
> Author: Kirk Lund 
> Date:   Tue Aug 16 09:25:33 2016 -0700
>
> GEODE-1781: exclude LinuxProcFsStatistics$CPU from
> AnaylzeSerializableJUnitTest
>
> 3) 1st line is 59 chars. To shorten to 50: "GEODE-1782: fix stat resource
> equals"
> (the later lines meet our guidelines)
>
> commit 7dc1ce68a483f993adeb613893073d8a7c88a9b7
> Author: Kirk Lund 
> Date:   Mon Aug 15 18:35:45 2016 -0700
>
> GEODE-1782: include start timestamp in stat resource equals
>
> * stat resources with different time stamps should not be equal
>
> * StatArchiveWithConsecutiveResourceInstGenerator generates gfs with
> multiple stat resources of same name but different times
>
> * StatArchiveWithConsecutiveResourceInstIntegrationTest confirms
> existence of bug GEODE-1782: StatArchiveReader ignores later stats
> resource with same name as closed stats resource
>
> * ResourceInstTest verifies the underlying issue and fix in
> StatArchiveReader.ResourceInst.equals and the fix
>
> 4) I got this one down to 48 chars!
> (the later lines meet our guidelines)
>
> commit 115070123ec15638ca1189a7349938c35e0d51e0
> Author: Kirk Lund 
> Date:   Mon Aug 15 18:26:16 2016 -0700
>
> GEODE-1781: refactor internal statistics classes
>
> * move internal statistics classes into com.gemstone.gemfire.internal.
> statistics
>
> * move statistics tests into com.gemstone.gemfire.internal.statistics
>
> * modify tests to include integration and distributed in names
>
> * modify tests to use TemporaryFolder and TestName rules
>
> On Wed, Aug 17, 2016 at 4:22 PM, Kenneth Howe  wrote:
>
> > Agree with Kirk, 50 chars is really short by the time you use up the
> first
> > 12 characters for the Jira tag. If we’re going to have a guideline, I’d
> > rather be longer - somewhat arbitrarily I’d probably make it 20-30 chars
> > more. It’s been a long time since text listings were intended to fit on a
> > 80x24 dumb terminal, so I don’t see a need to restrict the commit message
> > headers so severely.
> >
> > I do use the —online option embedded in a local alias I use to look at a
> > history list of my local repo.
> >
> > Ken
> >
> > > On Aug 17, 2016, at 3:45 PM, Kevin Duling  wrote:
> > >
> > > The format is very similar to the one most other git shops I've worked
> in
> > > before use.  I don't believe we ever had formal length limits.
> > Typically,
> > > it was:
> > >
> > > -: 
> > >>
> > > blank line
> > >
> > >  > ticket>
> > >
> > >
> > > The Atlassian plugin for IDEA automates a lot of this.  There are
> limits
> > on
> > > the length of a jira ticket summary, but I'm not sure what that is.  I
> > ran
> > > in to it when I did my round of CI.
> > >
> > > I don't see a reason to change anything except maybe stress that he
> > lengths
> > > are a guideline, not a hard & fast rule.  If more room is needed to
> write
> > > good information, it shouldn't be truncated as it's not unknown to move
> > > away from a given ticket system.
> > >
> > > On Wed, Aug 17, 2016 at 3:38 PM, Kirk Lund  wrote:
> > >
> > >> 50 chars including "GEODE-: " is awfully short.
> > >> http://chris.beams.io/posts/git-commit/ does say that's just a
> general
> > >> rule
> > >> of thumb and not a hard limit. The author's reasoning seems to be
> > >> specifically for using "git log --oneline" -- does anyone use that
> > option
> > >> with git log? I don't.
> > >>
> > >> I guess another option is to not have to have a guideline if we don't
> > want
> > >> one... our current git log messages are reasonable and make sense.
> > >>
> > >> -Kirk
> > >>
> > >>
> > >> On Wed, Aug 17, 2016 at 3:21 PM, Kirk Lund  wrote:
> > >>
> > >>> Here's the git commit message guidelines we discussed and voted on
> last
> > >>> year. I just checked and my own git commit message line lengths have
> > >> grown
> > >>> beyond what we decided to use. Most other are also not following this
> > >>> guideline.
> > >>>
> > >>> Here's the list of folks who voted last year along with their vote:
> > >>>
> > >>> Anthony Baker +1
> > >>> Vincent Ford +1
> > >>> William Markito