Re: Review Request 53414: GEODE-2065 Document defragmentationsInProgress statistic

2016-11-02 Thread Joey McAllister

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


Ship it!




Ship It!

- Joey McAllister


On Nov. 2, 2016, 11:52 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53414/
> ---
> 
> (Updated Nov. 2, 2016, 11:52 p.m.)
> 
> 
> Review request for geode, Dave Barnes, Darrel Schneider, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This is a sub-task of GEODE-1590.
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/statistics/statistics_list.html.md.erb 
> 07e4281f239b73896ed7b1b2fbb6429c87ac5024 
> 
> Diff: https://reviews.apache.org/r/53414/diff/
> 
> 
> Testing
> ---
> 
> gradle rat check passes
> 
> 
> Thanks,
> 
> Karen Miller
> 
>



Review Request 53414: GEODE-2065 Document defragmentationsInProgress statistic

2016-11-02 Thread Karen Miller

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

Review request for geode, Dave Barnes, Darrel Schneider, and Joey McAllister.


Repository: geode


Description
---

This is a sub-task of GEODE-1590.


Diffs
-

  geode-docs/reference/statistics/statistics_list.html.md.erb 
07e4281f239b73896ed7b1b2fbb6429c87ac5024 

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


Testing
---

gradle rat check passes


Thanks,

Karen Miller



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

2016-11-02 Thread anilkumar gingade

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

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


Repository: geode


Description
---

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

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

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

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

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


Diffs
-

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

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


Testing
---

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


Thanks,

anilkumar gingade



[GitHub] incubator-geode issue #276: GEODE-1993: postprocess region/key

2016-11-02 Thread kjduling
Github user kjduling commented on the issue:

https://github.com/apache/incubator-geode/pull/276
  
Don't accept this PR yet.  This is just a checkin to preserve work.

Addressed all of the issues listed above.  Added test for adhoc queries.  
Still need a test for named queries.  Also need to verify functions won't 
return any region data without being post-processed.

Have not run precheckin yet, either.


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


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

2016-11-02 Thread Jason Huynh

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




geode-core/src/test/java/org/apache/geode/internal/cache/execute/ClientServerFunctionExecutionDUnitTest.java
 (line 668)


the message is doing a list.get(0), but it should be doing a list.get(1)


- Jason Huynh


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



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

2016-11-02 Thread xiaojian zhou

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


Ship it!




Ship It!

- xiaojian zhou


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



Re: Review Request 53402: GEODE-2013: throw IllegalStateException if resource type is missing

2016-11-02 Thread Kirk Lund


> On Nov. 2, 2016, 8:26 p.m., Kevin Duling wrote:
> > What is the possibility of an ArrayIndexOutOfBoundsException on that 
> > assignment?

The ArrayIndexOutOfBoundsException message already contains the resourceTypeId 
because the array position is the type id. Still, it's a good idea and I'll add 
this to do when I overhaul these classes a bit more.


- Kirk


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


On Nov. 2, 2016, 8:07 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53402/
> ---
> 
> (Updated Nov. 2, 2016, 8:07 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Darrel Schneider, Jinmei Liao, Jared 
> Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2013
> https://issues.apache.org/jira/browse/GEODE-2013
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2013: throw IllegalStateException if resource type is missing
> 
> The StatArchiveReader was throwing NullPointerException if it found a 
> Resource without a ResourceType. Now it throws IllegalStateException with a 
> message explaining that no ResourceType for the specified resourceTypeId 
> could be found.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>  ca1a6c49269a56600191ac7b0551670ffb0f2c82 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53402/diff/
> 
> 
> Testing
> ---
> 
> StatArchiveWithMissingResourceTypeRegressionTest
> precheckin
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



Re: Review Request 53402: GEODE-2013: throw IllegalStateException if resource type is missing

2016-11-02 Thread Darrel Schneider

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


Ship it!




Ship It!

- Darrel Schneider


On Nov. 2, 2016, 1:07 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53402/
> ---
> 
> (Updated Nov. 2, 2016, 1:07 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Darrel Schneider, Jinmei Liao, Jared 
> Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2013
> https://issues.apache.org/jira/browse/GEODE-2013
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2013: throw IllegalStateException if resource type is missing
> 
> The StatArchiveReader was throwing NullPointerException if it found a 
> Resource without a ResourceType. Now it throws IllegalStateException with a 
> message explaining that no ResourceType for the specified resourceTypeId 
> could be found.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>  ca1a6c49269a56600191ac7b0551670ffb0f2c82 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53402/diff/
> 
> 
> Testing
> ---
> 
> StatArchiveWithMissingResourceTypeRegressionTest
> precheckin
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



Re: Apache policy on files types allowed in source code

2016-11-02 Thread Kirk Lund
I do have a particular case in mind involving stats files that geode
creates and reads. The StatArchiveWriter.java class writes out statistic
archive files for geode, while StatArchiveReader.java reads them in.

There have been a few bugs causing the stats files to be corrupted in some
way. My goal has been to fix the StatArchiveWriter to prevent any
corruption, but also fix the StatArchiveReader to self-correct where
possible or provide better error handling if self-correction is not
possible.

The result is that we have a couple regression tests under
geode-core/src/test/java with corresponding corrupted statistic archive
files under geode-core/src/test/resources.

Example: I currently have a review posted for GEODE-2013
https://reviews.apache.org/r/53402 with these files:

geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs

The above file StatArchiveWithMissingResourceTypeRegressionTest.gfs is
small (253 bytes on Mac). After fixing the source of the problem in
StatArchiveWriter (GEODE-2012), GEODE-2013 involves providing better error
messaging to the user if they try to read an older stats file that was
written before GEODE-2012 was fixed.

Thanks,
Kirk

On Wed, Nov 2, 2016 at 1:19 PM, Roman Shaposhnik 
wrote:

> On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
> > I'd like to read up on what's allowed and disallowed regarding file types
> > in Apache source code. Does anyone have any links to get me started?
>
> The only distinction that ASF makes is binaries vs. source files. The
> source
> code that ASF releases has to be comprised of files that can be called
> source (under a reasonable definition of source). The only requirement
> for source files is that they MUST be usable without leveraging commercial
> tools. Other than that -- anything goes.
>
> Are you asking with a particular example in mind or just asking a
> hypothetical?
>
> Thanks,
> Roman.
>


Re: Review Request 53402: GEODE-2013: throw IllegalStateException if resource type is missing

2016-11-02 Thread Jinmei Liao

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


Ship it!




Ship It!

- Jinmei Liao


On Nov. 2, 2016, 8:07 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53402/
> ---
> 
> (Updated Nov. 2, 2016, 8:07 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Darrel Schneider, Jinmei Liao, Jared 
> Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2013
> https://issues.apache.org/jira/browse/GEODE-2013
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2013: throw IllegalStateException if resource type is missing
> 
> The StatArchiveReader was throwing NullPointerException if it found a 
> Resource without a ResourceType. Now it throws IllegalStateException with a 
> message explaining that no ResourceType for the specified resourceTypeId 
> could be found.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>  ca1a6c49269a56600191ac7b0551670ffb0f2c82 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53402/diff/
> 
> 
> Testing
> ---
> 
> StatArchiveWithMissingResourceTypeRegressionTest
> precheckin
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



Re: Review Request 53402: GEODE-2013: throw IllegalStateException if resource type is missing

2016-11-02 Thread Kevin Duling

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



What is the possibility of an ArrayIndexOutOfBoundsException on that assignment?

- Kevin Duling


On Nov. 2, 2016, 1:07 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53402/
> ---
> 
> (Updated Nov. 2, 2016, 1:07 p.m.)
> 
> 
> Review request for geode, Anthony Baker, Darrel Schneider, Jinmei Liao, Jared 
> Stewart, and Kevin Duling.
> 
> 
> Bugs: GEODE-2013
> https://issues.apache.org/jira/browse/GEODE-2013
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-2013: throw IllegalStateException if resource type is missing
> 
> The StatArchiveReader was throwing NullPointerException if it found a 
> Resource without a ResourceType. Now it throws IllegalStateException with a 
> message explaining that no ResourceType for the specified resourceTypeId 
> could be found.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
>  ca1a6c49269a56600191ac7b0551670ffb0f2c82 
>   
> geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs
>  PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/53402/diff/
> 
> 
> Testing
> ---
> 
> StatArchiveWithMissingResourceTypeRegressionTest
> precheckin
> 
> 
> Thanks,
> 
> Kirk Lund
> 
>



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

2016-11-02 Thread 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)


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



Re: Apache policy on files types allowed in source code

2016-11-02 Thread Roman Shaposhnik
On Wed, Nov 2, 2016 at 1:16 PM, Kirk Lund  wrote:
> I'd like to read up on what's allowed and disallowed regarding file types
> in Apache source code. Does anyone have any links to get me started?

The only distinction that ASF makes is binaries vs. source files. The source
code that ASF releases has to be comprised of files that can be called
source (under a reasonable definition of source). The only requirement
for source files is that they MUST be usable without leveraging commercial
tools. Other than that -- anything goes.

Are you asking with a particular example in mind or just asking a hypothetical?

Thanks,
Roman.


Apache policy on files types allowed in source code

2016-11-02 Thread Kirk Lund
I'd like to read up on what's allowed and disallowed regarding file types
in Apache source code. Does anyone have any links to get me started?

Thanks,
Kirk


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

2016-11-02 Thread nabarun nag

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

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


Repository: geode


Description
---

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


Diffs
-

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

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


Testing
---

precheckin
IntelliJ multiple executions.


Thanks,

nabarun nag



Review Request 53402: GEODE-2013: throw IllegalStateException if resource type is missing

2016-11-02 Thread Kirk Lund

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

Review request for geode, Anthony Baker, Darrel Schneider, Jinmei Liao, Jared 
Stewart, and Kevin Duling.


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


Repository: geode


Description
---

GEODE-2013: throw IllegalStateException if resource type is missing

The StatArchiveReader was throwing NullPointerException if it found a Resource 
without a ResourceType. Now it throws IllegalStateException with a message 
explaining that no ResourceType for the specified resourceTypeId could be found.


Diffs
-

  
geode-core/src/main/java/org/apache/geode/internal/statistics/StatArchiveReader.java
 ca1a6c49269a56600191ac7b0551670ffb0f2c82 
  
geode-core/src/test/java/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.java
 PRE-CREATION 
  
geode-core/src/test/resources/org/apache/geode/internal/statistics/StatArchiveWithMissingResourceTypeRegressionTest.gfs
 PRE-CREATION 

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


Testing
---

StatArchiveWithMissingResourceTypeRegressionTest
precheckin


Thanks,

Kirk Lund



Re: Review Request 53399: Removing some string comparisons in the AttributesDescriptor

2016-11-02 Thread Jason Huynh


> On Nov. 2, 2016, 7:58 p.m., Jason Huynh wrote:
> > Ship It!

Do you think a unit test should be written for this?  Not sure how difficult or 
useful it would be...


- Jason


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


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



Re: Review Request 53399: Removing some string comparisons in the AttributesDescriptor

2016-11-02 Thread Jason Huynh

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


Ship it!




Ship It!

- Jason Huynh


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



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

2016-11-02 Thread Jason Huynh

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


Ship it!




Ship It!

- Jason Huynh


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



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

2016-11-02 Thread Scott Jewell

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


Ship it!




Ship It!

- Scott Jewell


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



Review Request 53399: Removing some string comparisons in the AttributesDescriptor

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

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



Re: Review Request 53388: GEODE-2059 client SSL handshake attempts do not time out

2016-11-02 Thread Udo Kohlmeyer

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


Ship it!




Ship It!

- Udo Kohlmeyer


On Nov. 2, 2016, 4:57 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53388/
> ---
> 
> (Updated Nov. 2, 2016, 4:57 p.m.)
> 
> 
> Review request for geode and Udo Kohlmeyer.
> 
> 
> Bugs: GEODE-2059
> https://issues.apache.org/jira/browse/GEODE-2059
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Client SSL connection attempts now time out during the SSL handshake
> 
> 
> Diffs
> -
> 
>   geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
> a3ba102f0680cacd10368d7bd4e43d9c47bc85f1 
>   
> geode-core/src/test/java/org/apache/geode/internal/net/SSLSocketIntegrationTest.java
>  d5a947cf40295328039159df2b5af5292cef724c 
> 
> Diff: https://reviews.apache.org/r/53388/diff/
> 
> 
> Testing
> ---
> 
> precheckin, new unit test
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>



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

2016-11-02 Thread anilkumar gingade

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




geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java 
(line 1755)


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


- anilkumar gingade


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



Re: jmh benchmarks

2016-11-02 Thread William Markito Oliveira
+1

Sent from my iPhone

> On Nov 2, 2016, at 11:35 AM, Udo Kohlmeyer  wrote:
> 
> +2
> 
> 
>> On 3/11/16 5:17 am, Dan Smith wrote:
>> 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
>> 
> 


Re: jmh benchmarks

2016-11-02 Thread Udo Kohlmeyer

+2


On 3/11/16 5:17 am, Dan Smith wrote:

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





Re: PMC nomination

2016-11-02 Thread Bruce Schuchardt

Great - thanks Greg

Le 11/2/2016 à 11:31 AM, Gregory Chase a écrit :

I saw your post to @private.

On Wed, Nov 2, 2016 at 11:27 AM, Bruce Schuchardt 
wrote:


I've been trying to join the private email list all morning &
self-nominate for the PMC if it's not too late








Re: PMC nomination

2016-11-02 Thread Gregory Chase
I saw your post to @private.

On Wed, Nov 2, 2016 at 11:27 AM, Bruce Schuchardt 
wrote:

> I've been trying to join the private email list all morning &
> self-nominate for the PMC if it's not too late
>



-- 
Greg Chase

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

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

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


PMC nomination

2016-11-02 Thread Bruce Schuchardt
I've been trying to join the private email list all morning & 
self-nominate for the PMC if it's not too late


Re: jmh benchmarks

2016-11-02 Thread Jared Stewart
+1 Jmh is great

On Nov 2, 2016 11:18 AM, "Dan Smith"  wrote:

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


jmh benchmarks

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


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

2016-11-02 Thread William Markito

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


Ship it!




Thanks for doing this Dan! Would love to see a README with instructions on how 
to get the results (for people not familiar with JMH) and integration of the 
results with Jenkins/CI so we have historical data.  Ship-it!

- William Markito


On Nov. 2, 2016, 6:11 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53395/
> ---
> 
> (Updated Nov. 2, 2016, 6:11 p.m.)
> 
> 
> 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
> 
>



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

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

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


Re: Backwards compatibility for 1.1

2016-11-02 Thread Anilkumar Gingade
Right, to be enterprise class software product, it needs to be backward
compatible...We also need to consider rolling upgrade of the system

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

-Anil.


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

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


Re: Backwards compatibility for 1.1

2016-11-02 Thread William Markito Oliveira
+1

On Wed, Nov 2, 2016 at 10:30 AM, Swapnil Bawaskar 
wrote:

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



-- 
~/William


Re: Backwards compatibility for 1.1

2016-11-02 Thread Swapnil Bawaskar
+1 for maintaining backwards compatibility.

On Wed, Nov 2, 2016 at 9:40 AM, Mark Bretl  wrote:

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


Review Request 53388: GEODE-2059 client SSL handshake attempts do not time out

2016-11-02 Thread Bruce Schuchardt

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

Review request for geode and Udo Kohlmeyer.


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


Repository: geode


Description
---

Client SSL connection attempts now time out during the SSL handshake


Diffs
-

  geode-core/src/main/java/org/apache/geode/internal/net/SocketCreator.java 
a3ba102f0680cacd10368d7bd4e43d9c47bc85f1 
  
geode-core/src/test/java/org/apache/geode/internal/net/SSLSocketIntegrationTest.java
 d5a947cf40295328039159df2b5af5292cef724c 

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


Testing
---

precheckin, new unit test


Thanks,

Bruce Schuchardt



Re: Backwards compatibility for 1.1

2016-11-02 Thread Mark Bretl
+1 for backward compatibility with Geode releases.

--Mark

On Wed, Nov 2, 2016 at 8:11 AM, Kenneth Howe  wrote:

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


Build failed in Jenkins: Geode-nightly #641

2016-11-02 Thread Apache Jenkins Server
See 

Changes:

[kmiller] GEODE-2045 Improve docs of region shortcuts

[klund] GEODE-2012: always write stat types to archive

[kmiller] GEODE-2047 Document change to enable-network-partition-detection

[upthewaterspout] Correcting javadocs on AsyncEventListener to return true.

[upthewaterspout] Changing geode-spark-connector to depend on 1.0 release.

[abaker] GEODE-2028: Fix license issues from 1.0.0-incubating release

[bschuchardt] GEODE-2051 - marking this test as flaky

[bschuchardt] GEODE-2051 - marking this test as flaky

--
[...truncated 526 lines...]
:geode-cq:check
:geode-cq:build
:geode-cq:distributedTest
:geode-cq:flakyTest
:geode-cq:integrationTest
:geode-json:assemble
:geode-json:compileTestJava UP-TO-DATE
:geode-json:processTestResources UP-TO-DATE
:geode-json:testClasses UP-TO-DATE
:geode-json:checkMissedTests UP-TO-DATE
:geode-json:spotlessJavaCheck
:geode-json:spotlessCheck
:geode-json:test UP-TO-DATE
:geode-json:check
:geode-json:build
:geode-json:distributedTest UP-TO-DATE
:geode-json:flakyTest UP-TO-DATE
:geode-json:integrationTest UP-TO-DATE
:geode-junit:javadoc
:geode-junit:javadocJar
:geode-junit:sourcesJar
:geode-junit:signArchives SKIPPED
:geode-junit:assemble
:geode-junit:compileTestJava
:geode-junit:processTestResources UP-TO-DATE
:geode-junit:testClasses
:geode-junit:checkMissedTests
:geode-junit:spotlessJavaCheck
:geode-junit:spotlessCheck
:geode-junit:test
:geode-junit:check
:geode-junit:build
:geode-junit:distributedTest
:geode-junit:flakyTest
:geode-junit:integrationTest
:geode-lucene:assemble
:geode-lucene:compileTestJavaNote: Some input files use or override a 
deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-lucene:processTestResources
:geode-lucene:testClasses
:geode-lucene:checkMissedTests
:geode-lucene:spotlessJavaCheck
:geode-lucene:spotlessCheck
:geode-lucene:test
:geode-lucene:check
:geode-lucene:build
:geode-lucene:distributedTest
:geode-lucene:flakyTest
:geode-lucene:integrationTest
:geode-old-client-support:assemble
:geode-old-client-support:compileTestJava
:geode-old-client-support:processTestResources UP-TO-DATE
:geode-old-client-support:testClasses
:geode-old-client-support:checkMissedTests
:geode-old-client-support:spotlessJavaCheck
:geode-old-client-support:spotlessCheck
:geode-old-client-support:test
:geode-old-client-support:check
:geode-old-client-support:build
:geode-old-client-support:distributedTest
:geode-old-client-support:flakyTest
:geode-old-client-support:integrationTest
:geode-pulse:assemble
:geode-pulse:compileTestJavaNote: 

 uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-pulse:processTestResources
:geode-pulse:testClasses
:geode-pulse:checkMissedTests
:geode-pulse:spotlessJavaCheck
:geode-pulse:spotlessCheck
:geode-pulse:test
:geode-pulse:check
:geode-pulse:build
:geode-pulse:distributedTest
:geode-pulse:flakyTest
:geode-pulse:integrationTest
:geode-rebalancer:assemble
:geode-rebalancer:compileTestJava
:geode-rebalancer:processTestResources UP-TO-DATE
:geode-rebalancer:testClasses
:geode-rebalancer:checkMissedTests
:geode-rebalancer:spotlessJavaCheck
:geode-rebalancer:spotlessCheck
:geode-rebalancer:test
:geode-rebalancer:check
:geode-rebalancer:build
:geode-rebalancer:distributedTest
:geode-rebalancer:flakyTest
:geode-rebalancer:integrationTest
:geode-wan:assemble
:geode-wan:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-wan:processTestResources
:geode-wan:testClasses
:geode-wan:checkMissedTests
:geode-wan:spotlessJavaCheck
:geode-wan:spotlessCheck
:geode-wan:test
:geode-wan:check
:geode-wan:build
:geode-wan:distributedTest
:geode-wan:flakyTest
:geode-wan:integrationTest
:geode-web:assemble
:geode-web:compileTestJavaNote: Some input files use or override a deprecated 
API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

:geode-web:processTestResources UP-TO-DATE
:geode-web:testClasses
:geode-web:checkMissedTests
:geode-web:spotlessJavaCheck
:geode-web:spotlessCheck
:geode-web:test
:geode-web:check
:geode-web:build
:geode-web:distributedTest
:geode-web:flakyTest
:geode-web:integrationTest
:geode-web-api:assemble
:geode-web-api:compileTestJava UP-TO-DATE
:geode-web-api:processTestResources UP-TO-DATE
:geode-web-api

Re: Review Request 53360: GEODE-2050 Remove doc of statistics no longer present

2016-11-02 Thread Bruce Schuchardt

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


Ship it!




Ship It!

- Bruce Schuchardt


On Nov. 1, 2016, 11:55 p.m., Karen Miller wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53360/
> ---
> 
> (Updated Nov. 1, 2016, 11:55 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt, Dave Barnes, and Joey McAllister.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> JGroups-related statistics were removed in the first commit. New membership 
> service-related statistics were added in the second commit.
> 
> 
> Diffs
> -
> 
>   geode-docs/reference/statistics/statistics_list.html.md.erb 
> 227f8dfda8747d00b2e9077f920646d68f3f8acf 
> 
> Diff: https://reviews.apache.org/r/53360/diff/
> 
> 
> Testing
> ---
> 
> Gradle rat check passes.
> 
> 
> Thanks,
> 
> Karen Miller
> 
>



Re: Backwards compatibility for 1.1

2016-11-02 Thread Kenneth Howe
+1 to Dan
+1 to Bruce - the distributedTest extensions for backward compatibility would 
great

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