date:20160318

Re: Review Request 44877: GEODE-27: Adding a test to verify the bundled jars have not changed

2016-03-18 Thread Mark Bretl

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

Can anything be done not to have static versions of jars in the 
expected_jars.txt? This now introduces having to update two different places 
again for dependencies and if we move back to transitive dependencies, then we 
have to manage those as well. I am definitely for making sure we keep tracking 
of adding dependencies and what we include in the distribution, however, I can 
see this getting out of sync. Myabe that is way it needs to be though.

- Mark Bretl

On March 15, 2016, 6:23 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44877/
> ---
> 
> (Updated March 15, 2016, 6:23 p.m.)
> 
> 
> Review request for geode, Anthony Baker and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This allows us to make sure we don't accidentally start shipping jars
> that we didn't intend to.
> 
> 
> Diffs
> -
> 
>   geode-assembly/src/test/java/com/gemstone/gemfire/BundledJarsJUnitTest.java 
> PRE-CREATION 
>   geode-assembly/src/test/resources/expected_jars.txt PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/44877/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: Review Request 44936: Changed references of off-heap compaction to defragmentation

2016-03-18 Thread Darrel Schneider


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




geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
 (line 72)


typo: change deframenting to defragmenting



geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorFillPatternJUnitTest.java
 (line 54)


typo: change "ATA" to "TA"



geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapRegionBase.java
 (line 102)


typo: change "product" to "produce"


- Darrel Schneider


On March 16, 2016, 3:29 p.m., Sai Boorlagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44936/
> ---
> 
> (Updated March 16, 2016, 3:29 p.m.)
> 
> 
> Review request for geode and Darrel Schneider.
> 
> 
> Bugs: GEODE-1017
> https://issues.apache.org/jira/browse/GEODE-1017
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Changed references of off-heap compaction to defragmentation
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/Fragment.java 
> 0ea6cf84090912957124b471901a46f49c6fd51c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
>  c943a7e934db1eff74df9299e52378a6f6b6eba1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorImpl.java
>  2050dd4e82ec128ae4c60eb2a815d014ca7fadf5 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapMemoryStats.java
>  790e43df870e9c32aa718c0c883e4ab567dd824b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
>  2bdcfba4be05a8f069997c63d374def516b33689 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/beans/MemberMBeanBridge.java
>  61e328d0d632cf760fd1d7d3ee7833833b596891 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
>  950d90be8491d4316147a49c1fd0b662ad340fd2 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorFillPatternJUnitTest.java
>  f1d223dbd1a621073b5be7140b5a07adc50da957 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorJUnitTest.java
>  7639f8d125e74d4bf78940c901c689cec1804107 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/NullOffHeapMemoryStats.java
>  88bab77c90e285941b1ef04db65177e6fbf9cbcd 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapRegionBase.java
>  fb1aa41fd5ffbc746eb31dabf4d2c15850fa9c4c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapStorageJUnitTest.java
>  d30d4c44d0d7141584aaadf4193e2da43746c63c 
> 
> Diff: https://reviews.apache.org/r/44936/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sai Boorlagadda
> 
>

Re: Can we close GEODE-36 ? (Gfsh renaming)

2016-03-18 Thread Gregory Chase

+1, but only if its "Geode Fab-SHell"

On Wed, Mar 16, 2016 at 8:54 AM, Michael Stolz  wrote:

> +1
> Or Geode Fabric SHell
>
> We used to call it a Data Fabric at one time :)
>
> --
> Mike Stolz
> Principal Engineer, GemFire Product Manager
> Mobile: 631-835-4771
>
> On Wed, Mar 16, 2016 at 10:19 AM, Anthony Baker  wrote:
>
> > +1
> >
> > I think Geode Fabulous SHell is a reasonable name.  Changing it generates
> > a ton of work both in the code and documentation without much benefit
> IMO.
> >
> > Link to the original discussion:
> >
> >
> https://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/%3cCAF3UAT1FRANKyLUXeSG-m6yNXnTyw=3heo5350vf-80hvfz...@mail.gmail.com%3e
> >
> > Anthony
> >
> >
> > > On Mar 15, 2016, at 9:41 PM, William Markito 
> > wrote:
> > >
> > > Howdy!
> > >
> > > Looks like we had this discussion in the past but given my own current
> > > understanding of the impacts and needs for such change, I'd like to ask
> > if
> > > we can close GEODE-36 with the changes Nitin already did to display the
> > > product name properly and keep it as is...
> > >
> > >
> > > We can even update the banner if that's a thing, but I'm giving my +1
> to
> > > keep it gfsh.
> > >
> > > o   o
> > >  /^7
> > >'  ' ,oOOo,
> > >   ,'))), /{
> > >  '  ,'o  ={
> > >>   ={
> > > `,   ))\ \)))={
> > >   ',\/)' \{
> > > '*OO*'
> > >
> > >
> > > --
> > >
> > > ~/William
> >
> >
>



-- 
Greg Chase

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

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

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

Review Request 44990: GEODE-947 Client log message misleading

2016-03-18 Thread Bruce Schuchardt


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

Review request for geode, Darrel Schneider, Hitesh Khamesra, Jianxia Chen, and 
Udo Kohlmeyer.


Repository: geode


Description
---

Logging of local-mode or client-mode is now done in GemFireCacheImpl when the 
cache is created.  If there is a connection pool or the cache is marked 
isClient we want to say it's running in client-mode.  If it's not in 
client-mode and the DistributedSystem is not actually configured to be able to 
distribute anything we say it's running in local-mode.

I corrected the text of the local-mode message to remove the reference to 
multicast since multicast discovery is not supported in Geode.


Diffs
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
 201acc015bf1729fbfacb03e68fa1c2f0fdb7e09 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/i18n/ParentLocalizedStrings.java
 248353fe6130d27c109b1c738de99b40512876ea 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/logging/LogWriterFactory.java
 f08847abd5ed9f11441eefbb0de2b9c0d52028f9 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/logging/log4j/LogWriterAppenders.java
 7dd936614142343f9e660be212868678154b5526 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/logging/TestLogWriterFactory.java
 4c46503d3f773f4cb5c3a2c35bdae2090f9ac0ca 

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


Testing
---

precheckin testing is underway


Thanks,

Bruce Schuchardt

[GitHub] incubator-geode pull request: GEODE-247: Fix in executeQuery funct...

2016-03-18 Thread nabarunnag

Github user nabarunnag commented on the pull request:

https://github.com/apache/incubator-geode/pull/112#issuecomment-198073859
  
Will start a new pull request with the code modification suggested in the 
comments for this pull request.


---
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 45048: GEODE-559: CI Failure: ClientInterestNotifyDUnitTest.testInterestNotify failed

2016-03-18 Thread Jason Huynh


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




geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/ClientInterestNotifyDUnitTest.java
 (line 109)


Are destroys the final events that are supposed to arrive? just wondering 
if this criteria should include the other event types as well.


- Jason Huynh


On March 18, 2016, 9:16 p.m., anilkumar gingade wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45048/
> ---
> 
> (Updated March 18, 2016, 9:16 p.m.)
> 
> 
> Review request for geode, anilkumar gingade, Barry Oglesby, Jason Huynh, 
> nabarun nag, Dan Smith, and xiaojian zhou.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Test issue. Before validation test checks to see if the events are drained on 
> the server side, but doesn't count for time taken to receive the event on 
> client side and invoke its cache listener. Based on the machine speed and 
> thread invocation timing, this test can intermediately fail.
> 
> Added wait logic at client side CacheListener.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/ClientInterestNotifyDUnitTest.java
>  1559506d068fe03f4f46de67abeab147ce08cf4a 
> 
> Diff: https://reviews.apache.org/r/45048/diff/
> 
> 
> Testing
> ---
> 
> Run the test by simulating the problem (using sleep and changing the count) 
> and validated test working as expected.
> 
> 
> Thanks,
> 
> anilkumar gingade
> 
>

Build failed in Jenkins: Geode-nightly #413

2016-03-18 Thread Apache Jenkins Server

See 

Changes:

[bschuchardt] GEODE-947 Client log message misleading

[hkhamesra] GEODE-1100 Neglect view when it send by member which is not in 
current

[hkhamesra] GEODE-519 Make sure that membership port range is available.

[hkhamesra] GEODE-514 Make sure we look for quorum only when networkPartition is

[hkhamesra] GEODE-515 Make sure that we connect to DS using same udp port.

[hkhamesra] GEODE-1100 Fixed test issue. Set Sender in InstallViewMessage.

[hkhamesra] GEODE-1106 test was setting testHook asynchronously. Now it set

[agingade] GEODE-934: CI failure:

[klund] GEODE-1112: Fix templates.security to

[huynhja] GEODE-1044: InitialImagePut executes BEFORE_UPDATE_OP on indexes for

[huynhja] GEODE-249: Retry on local node does not overwrite previously retrieved

[huynhja] GEODE-249: Added license header to test

[upthewaterspout] GEODE-27: A couple of tools to dump dependencies

[upthewaterspout] GEODE-27: Removing a bogus include of a jetty class

[upthewaterspout] GEODE-27: Enabling transitive dependencies in the build

[upthewaterspout] GEODE-27: Marking jars as optional in the generated pom

[upthewaterspout] GEODE-27: Adding a test to verify the bundled jars have not 
changed

[upthewaterspout] GEODE-27: Moving findbugs annotations to geode-core

[upthewaterspout] GEODE-27: Removing some forced dependencies

[huynhja] GEODE-1044: Adding license header to added xml file

[klund] GEODE-1050: add JUnit 4 versions of DistributedTestCase and

[hkhamesra] GEODE-936 test now catches expected

--
[...truncated 84 lines...]
Download 
https://plugins.gradle.org/m2/com/github/zafarkhaja/java-semver/0.9.0/java-semver-0.9.0.pom
Download 
https://plugins.gradle.org/m2/org/eclipse/jgit/org.eclipse.jgit/4.0.1.201506240215-r/org.eclipse.jgit-4.0.1.201506240215-r.pom
Download 
https://plugins.gradle.org/m2/org/eclipse/jgit/org.eclipse.jgit-parent/4.0.1.201506240215-r/org.eclipse.jgit-parent-4.0.1.201506240215-r.pom
Download 
https://plugins.gradle.org/m2/org/eclipse/jgit/org.eclipse.jgit.ui/4.0.1.201506240215-r/org.eclipse.jgit.ui-4.0.1.201506240215-r.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.jsch/0.0.9/jsch.agentproxy.jsch-0.0.9.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy/0.0.9/jsch.agentproxy-0.0.9.pom
Download 
https://plugins.gradle.org/m2/org/sonatype/oss/oss-parent/6/oss-parent-6.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.pageant/0.0.9/jsch.agentproxy.pageant-0.0.9.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.sshagent/0.0.9/jsch.agentproxy.sshagent-0.0.9.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.usocket-jna/0.0.9/jsch.agentproxy.usocket-jna-0.0.9.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.usocket-nc/0.0.9/jsch.agentproxy.usocket-nc-0.0.9.pom
Download 
https://plugins.gradle.org/m2/org/slf4j/slf4j-api/1.7.12/slf4j-api-1.7.12.pom
Download 
https://plugins.gradle.org/m2/org/slf4j/slf4j-parent/1.7.12/slf4j-parent-1.7.12.pom
Download https://plugins.gradle.org/m2/com/jcraft/jsch/0.1.51/jsch-0.1.51.pom
Download 
https://plugins.gradle.org/m2/com/googlecode/javaewah/JavaEWAH/0.7.9/JavaEWAH-0.7.9.pom
Download 
https://plugins.gradle.org/m2/org/apache/httpcomponents/httpclient/4.1.3/httpclient-4.1.3.pom
Download 
https://plugins.gradle.org/m2/org/apache/httpcomponents/httpcomponents-client/4.1.3/httpcomponents-client-4.1.3.pom
Download 
https://plugins.gradle.org/m2/org/apache/httpcomponents/project/5/project-5.pom
Download 
https://plugins.gradle.org/m2/com/jcraft/jsch.agentproxy.core/0.0.9/jsch.agentproxy.core-0.0.9.pom
Download https://plugins.gradle.org/m2/net/java/dev/jna/jna/4.1.0/jna-4.1.0.pom
Download 
https://plugins.gradle.org/m2/net/java/dev/jna/jna-platform/4.1.0/jna-platform-4.1.0.pom
Download 
https://plugins.gradle.org/m2/org/apache/httpcomponents/httpcore/4.1.4/httpcore-4.1.4.pom
Download 
https://plugins.gradle.org/m2/org/apache/httpcomponents/httpcomponents-core/4.1.4/httpcomponents-core-4.1.4.pom
Download 
https://plugins.gradle.org/m2/gradle/plugin/org/nosphere/apache/creadur-rat-gradle/0.2.0/creadur-rat-gradle-0.2.0.jar
Download 
https://plugins.gradle.org/m2/org/ajoberstar/gradle-git/1.3.2/gradle-git-1.3.2.jar
Download 
https://plugins.gradle.org/m2/com/bmuschko/gradle-nexus-plugin/2.3.1/gradle-nexus-plugin-2.3.1.jar
Download 
https://plugins.gradle.org/m2/org/ajoberstar/grgit/1.4.1/grgit-1.4.1.jar
Download 
https://plugins.gradle.org/m2/com/github/zafarkhaja/java-semver/0.9.0/java-semver-0.9.0.jar
Download 
https://plugins.gradle.org/m2/org/eclipse/jgit/org.eclipse.jgit/4.0.1.201506240215-r/org.eclipse.jgit-4.0.1.201506240215-r.jar
Download 
https://plugins.gradle.org/m2/org/eclipse/jgit/org.eclipse.jgit.ui/4.0.1.201506240215-r/org.eclipse.jgit.ui-4.0.1.201506240215-r.jar
Download

Re: Review Request 44869: Fixed updateStateAndSendEvent to consider testBytesUsedForThresholdSet

2016-03-18 Thread Sai Boorlagadda


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

(Updated March 16, 2016, 8:10 p.m.)


Review request for geode, Darrel Schneider, Eric Shu, and Swapnil Bawaskar.


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


Repository: geode


Description
---

Fixed updateStateAndSendEvent to consider testBytesUsedForThresholdSet


Diffs (updated)
-

  
geode-core/src/main/java/com/gemstone/gemfire/internal/cache/control/HeapMemoryMonitor.java
 27a6dffe8d41bbb3dbe44700e4980b513bb07121 

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


Testing
---

precheckin and regression tests


Thanks,

Sai Boorlagadda

Re: Review Request 44877: GEODE-27: Adding a test to verify the bundled jars have not changed

2016-03-18 Thread anilkumar gingade


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


Fix it, then Ship it!




Ship It!


geode-assembly/src/test/java/com/gemstone/gemfire/BundledJarsJUnitTest.java 
(line 78)


Does this work on WindowsOr can we ignore windows platform?


- anilkumar gingade


On March 16, 2016, 1:23 a.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44877/
> ---
> 
> (Updated March 16, 2016, 1:23 a.m.)
> 
> 
> Review request for geode, Anthony Baker and Jason Huynh.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> This allows us to make sure we don't accidentally start shipping jars
> that we didn't intend to.
> 
> 
> Diffs
> -
> 
>   geode-assembly/src/test/java/com/gemstone/gemfire/BundledJarsJUnitTest.java 
> PRE-CREATION 
>   geode-assembly/src/test/resources/expected_jars.txt PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/44877/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

[GitHub] incubator-geode pull request: Geode-54: missing javadocs

2016-03-18 Thread davebarnes97

Github user davebarnes97 closed the pull request at:

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


---
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 44968: GEODE-27: Further build cleanup - removing some forced dependencies and moving findbugs annotations to geode-core

2016-03-18 Thread Dan Smith



> On March 17, 2016, 6:58 p.m., Mark Bretl wrote:
> > gradle/java.gradle, line 97
> > 
> >
> > Is there ever a time where a sub-project is not dependent on geode-core 
> > and would use the findbugs-annotations?
> > 
> > No issue moving it now since we don't have that configuration now, 
> > however, might need to move it back later.

At that point, I think they can just add findbugs-annotations to the 
dependencies of that project. But most of the sub projects don't actually need 
this dependency. I also wanted to completely git rid of place where people can 
add dependencies to all projects, because people were putting jars in there 
that didn't need to be there. Jason just spent a while moving some spring jars 
out of this spot.


- Dan


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


On March 17, 2016, 5:52 p.m., Dan Smith wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44968/
> ---
> 
> (Updated March 17, 2016, 5:52 p.m.)
> 
> 
> Review request for geode, Jason Huynh and Jens Deppe.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> A few more things to clean up our dependencies a bit.
> 
> We really shouldn't have any dependencies that are included for all projects. 
> Moving the findbugs annotations in to geode core. Unfortunately, I still had 
> to leave it as compile scope just so that downstream consumers won't get 
> warnings when they compile against the geode jar.
> 
> Removing a few forced versions that don't seem to be necessary.
> 
> 
> Diffs
> -
> 
>   geode-assembly/build.gradle 5930f13c5307e0cd70396b019263176a377d415a 
>   geode-assembly/src/test/resources/expected_jars.txt PRE-CREATION 
>   geode-core/build.gradle 041dc07c860c008f117d37969ee688375c2a348d 
>   gradle/dependency-resolution.gradle PRE-CREATION 
>   gradle/java.gradle PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/44968/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Dan Smith
> 
>

Re: [DISCUSS] M2 issues - what's included and how we're tracking them

2016-03-18 Thread William Markito

+1

On Fri, Mar 18, 2016 at 3:12 PM, Anthony Baker  wrote:

> +1
>
> I would also consider:
>
> GEODE-818
> GEODE-835
>
> Anthony
>
> > On Mar 18, 2016, at 3:00 PM, Dan Smith  wrote:
> >
> > If we do that, I think we should remove a few more things from the "Must
> > Fix" list:
> > GEODE-33 Create project examples
> > GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5,
> asc.sha1)
>
>


-- 

~/William

Re: Can we close GEODE-36 ? (Gfsh renaming)

2016-03-18 Thread William Markito

Thank you all folks! I'll put that to bed then...


On Wed, Mar 16, 2016 at 10:05 AM, Kenneth Howe  wrote:

> +1
>
> > On Mar 16, 2016, at 9:57 AM, Dan Smith  wrote:
> >
> > +1 to gfsh, and +1 to William's ascii art!
> >
> > -Dan
> >
> >
> >
> >
> >
> > On Wed, Mar 16, 2016 at 9:32 AM, Jens Deppe  wrote:
> >
> >> +1
> >>
> >> On Wed, Mar 16, 2016 at 8:58 AM, Gregory Chase 
> wrote:
> >>
> >>> +1, but only if its "Geode Fab-SHell"
> >>>
> >>> On Wed, Mar 16, 2016 at 8:54 AM, Michael Stolz 
> >> wrote:
> >>>
>  +1
>  Or Geode Fabric SHell
> 
>  We used to call it a Data Fabric at one time :)
> 
>  --
>  Mike Stolz
>  Principal Engineer, GemFire Product Manager
>  Mobile: 631-835-4771
> 
>  On Wed, Mar 16, 2016 at 10:19 AM, Anthony Baker 
> >>> wrote:
> 
> > +1
> >
> > I think Geode Fabulous SHell is a reasonable name.  Changing it
> >>> generates
> > a ton of work both in the code and documentation without much benefit
>  IMO.
> >
> > Link to the original discussion:
> >
> >
> 
> >>>
> >>
> https://mail-archives.apache.org/mod_mbox/incubator-geode-dev/201505.mbox/%3cCAF3UAT1FRANKyLUXeSG-m6yNXnTyw=3heo5350vf-80hvfz...@mail.gmail.com%3e
> >
> > Anthony
> >
> >
> >> On Mar 15, 2016, at 9:41 PM, William Markito 
> > wrote:
> >>
> >> Howdy!
> >>
> >> Looks like we had this discussion in the past but given my own
> >>> current
> >> understanding of the impacts and needs for such change, I'd like to
> >>> ask
> > if
> >> we can close GEODE-36 with the changes Nitin already did to display
> >>> the
> >> product name properly and keep it as is...
> >>
> >>
> >> We can even update the banner if that's a thing, but I'm giving my
> >> +1
>  to
> >> keep it gfsh.
> >>
> >> o   o
> >> /^7
> >>   '  ' ,oOOo,
> >>  ,'))), /{
> >> '  ,'o  ={
> >>>  ={
> >>`,   ))\ \)))={
> >>  ',\/)' \{
> >>'*OO*'
> >>
> >>
> >> --
> >>
> >> ~/William
> >
> >
> 
> >>>
> >>>
> >>>
> >>> --
> >>> 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/
> >>>
> >>
>
>


-- 

~/William

Re: Review Request 44977: GEODE-949: refactor and repackage security test code

2016-03-18 Thread Jens Deppe


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


Ship it!




Ship It!

- Jens Deppe


On March 17, 2016, 8:04 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44977/
> ---
> 
> (Updated March 17, 2016, 8:04 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Jinmei Liao, and William Markito.
> 
> 
> Bugs: GEODE-949
> https://issues.apache.org/jira/browse/GEODE-949
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-949: refactor and repackage security test code
> 
> Uploading the full diffs for Geode here.
> 
> * test security classes under security package are now in 
> com.gemstone.gemfire.security.generator
> * test security resources under lib package are now in 
> com.gemstone.gemfire.security.generator
> * test security classes under templates.security package are now in 
> com.gemstone.gemfire.security.templates
> * fixed places where security code was eating exceptions
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/distributed/internal/membership/gms/auth/GMSAuthenticator.java
>  ba35e46 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/CacheServerSSLConnectionDUnitTest.java
>  5fa4fc4 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/cache/tier/sockets/DurableClientBug39997DUnitTest.java
>  fb8fb3e 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/ClientAuthenticationDUnitTest.java
>  8446eae 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/ClientAuthorizationDUnitTest.java
>  1d0b481 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/ClientAuthorizationTestBase.java
>  55edaa1 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/ClientMultiUserAuthzDUnitTest.java
>  dc03990 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/DeltaClientAuthorizationDUnitTest.java
>  5c184d1 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/DeltaClientPostAuthorizationDUnitTest.java
>  ec1c692 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/P2PAuthenticationDUnitTest.java
>  d47b1c4 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/AuthzCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/CredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/DummyAuthzCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/DummyCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/LdapUserCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/PKCSCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/SSLCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/UserPasswordWithExtraPropsAuthInit.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/generator/XmlAuthzCredentialGenerator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/DummyAuthenticator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/DummyAuthorization.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/FunctionSecurityPrmsHolder.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/LdapUserAuthenticator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/PKCSAuthInit.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/PKCSAuthenticator.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/PKCSPrincipal.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/PKCSPrincipalTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/UserPasswordAuthInit.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/UsernamePrincipal.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/UsernamePrincipalTest.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/XmlAuthorization.java
>  PRE-CREATION 
>   
> geode-core/src/test/java/com/gemstone/gemfire/security/templates/XmlErrorHandler.java
>

Re: Review Request 44929: GEODE-1067: The dispatcher now handles IllegalStateException by retrying batch without the released event

2016-03-18 Thread Barry Oglesby



> On March 17, 2016, 5:06 p.m., Dan Smith wrote:
> > What are the reasons why the serialized value is not available? Could this 
> > change cause us to drop events without realizing it due to bugs in getting 
> > the off heap value?

The data PR is locally destroyed which in turn locally destroys the queue PR. 
This clears the AbstractRegionMap which iterates the entries and releases them:

[warn 2016/03/17 12:37:45.423 PDT  tid=0x13] 
AAA GatewaySenderEventImpl.release released key: 5
java.lang.Exception
at 
com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventImpl.release(GatewaySenderEventImpl.java:1259)
at 
com.gemstone.gemfire.internal.cache.wan.GatewaySenderEventImpl.release(GatewaySenderEventImpl.java:1265)
at 
com.gemstone.gemfire.internal.util.concurrent.CustomEntryConcurrentHashMap$Segment.clear(CustomEntryConcurrentHashMap.java:1114)
at 
com.gemstone.gemfire.internal.util.concurrent.CustomEntryConcurrentHashMap.clear(CustomEntryConcurrentHashMap.java:1976)
at 
com.gemstone.gemfire.internal.cache.AbstractRegionMap._mapClear(AbstractRegionMap.java:421)
at 
com.gemstone.gemfire.internal.cache.AbstractRegionMap.clear(AbstractRegionMap.java:467)
at 
com.gemstone.gemfire.internal.cache.AbstractLRURegionMap.clear(AbstractLRURegionMap.java:678)
at 
com.gemstone.gemfire.internal.cache.AbstractRegionMap.close(AbstractRegionMap.java:432)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.closeEntries(LocalRegion.java:2979)
at 
com.gemstone.gemfire.internal.cache.AbstractBucketRegionQueue.access$001(AbstractBucketRegionQueue.java:52)
at 
com.gemstone.gemfire.internal.cache.AbstractBucketRegionQueue$1.run(AbstractBucketRegionQueue.java:503)
at 
com.gemstone.gemfire.internal.offheap.OffHeapRegionEntryHelper.doWithOffHeapClear(OffHeapRegionEntryHelper.java:409)
at 
com.gemstone.gemfire.internal.cache.AbstractBucketRegionQueue.closeEntries(AbstractBucketRegionQueue.java:500)
at 
com.gemstone.gemfire.internal.cache.BucketRegionQueue.access$001(BucketRegionQueue.java:61)
at 
com.gemstone.gemfire.internal.cache.BucketRegionQueue$2.run(BucketRegionQueue.java:227)
at 
com.gemstone.gemfire.internal.offheap.OffHeapRegionEntryHelper.doWithOffHeapClear(OffHeapRegionEntryHelper.java:409)
at 
com.gemstone.gemfire.internal.cache.BucketRegionQueue.closeEntries(BucketRegionQueue.java:224)
at 
com.gemstone.gemfire.internal.cache.DiskStoreImpl.basicDestroy(DiskStoreImpl.java:2673)
at 
com.gemstone.gemfire.internal.cache.DiskStoreImpl.endDestroyRegion(DiskStoreImpl.java:3273)
at 
com.gemstone.gemfire.internal.cache.AbstractDiskRegion.endDestroy(AbstractDiskRegion.java:564)
at 
com.gemstone.gemfire.internal.cache.AbstractDiskRegion.beginDestroy(AbstractDiskRegion.java:581)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.closePartitionedRegion(PartitionedRegion.java:7694)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.postDestroyRegion(PartitionedRegion.java:8362)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2948)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6886)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.destroyParallelGatewaySenderRegion(PartitionedRegion.java:7901)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6871)
at 
com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6834)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.localDestroyRegion(PartitionedRegion.java:7984)
at 
com.gemstone.gemfire.internal.cache.PartitionedRegion.localDestroyRegion(PartitionedRegion.java:7945)
at 
com.gemstone.gemfire.internal.cache.AbstractRegion.localDestroyRegion(AbstractRegion.java:354)
at 
com.gemstone.gemfire.internal.cache.wan.WANTestBase.localDestroyRegion(WANTestBase.java:3212)

There are a few things that could be looked at:

After a GatewaySenderEventImpl is peeked from the queue in 
ParallelGatewaySenderQueue.peek, makeHeapCopyIfOffHeap is invoked on it. That 
call doesn't really do anything.

Basically the test in GatewaySenderEventImpl.makeHeapCopyIfOffHeap (below) is 
false because hasRefCount is false so 'this' is returned (no copy is made). 
Should hasRefCount return true here? If it did return true, then a copy would 
be made, and I think this issue would be resolved.

if (v instanceof StoredObject && ((StoredObject) v).hasRefCount()) {

Also, the queue PR is being destroyed with cacheWrite=false (set in 
PartitionedRegion.localDestroyRegion):

[warn 2016/03/17 12:31:38.057 PDT  tid=0x13] 
AAA PartitionedRegion.destroyParallelGatewaySenderRegion destroying queue 
region /ln2_PARALLEL_GATEWAY_SENDER_QUEUE; cacheWrite: false
java.lang.Exception
at

[GitHub] incubator-geode pull request: Geode-54: missing javadocs

2016-03-18 Thread davebarnes97

Github user davebarnes97 commented on the pull request:

https://github.com/apache/incubator-geode/pull/115#issuecomment-197613902
  
Merged and Closed manually due to spurious Travis failure.


---
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 44990: GEODE-947 Client log message misleading

2016-03-18 Thread Jianxia Chen


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


Ship it!




Ship It!

- Jianxia Chen


On March 17, 2016, 10:50 p.m., Bruce Schuchardt wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44990/
> ---
> 
> (Updated March 17, 2016, 10:50 p.m.)
> 
> 
> Review request for geode, Darrel Schneider, Hitesh Khamesra, Jianxia Chen, 
> and Udo Kohlmeyer.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Logging of local-mode or client-mode is now done in GemFireCacheImpl when the 
> cache is created.  If there is a connection pool or the cache is marked 
> isClient we want to say it's running in client-mode.  If it's not in 
> client-mode and the DistributedSystem is not actually configured to be able 
> to distribute anything we say it's running in local-mode.
> 
> I corrected the text of the local-mode message to remove the reference to 
> multicast since multicast discovery is not supported in Geode.
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/cache/GemFireCacheImpl.java
>  201acc015bf1729fbfacb03e68fa1c2f0fdb7e09 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/i18n/ParentLocalizedStrings.java
>  248353fe6130d27c109b1c738de99b40512876ea 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/logging/LogWriterFactory.java
>  f08847abd5ed9f11441eefbb0de2b9c0d52028f9 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/logging/log4j/LogWriterAppenders.java
>  7dd936614142343f9e660be212868678154b5526 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/logging/TestLogWriterFactory.java
>  4c46503d3f773f4cb5c3a2c35bdae2090f9ac0ca 
> 
> Diff: https://reviews.apache.org/r/44990/diff/
> 
> 
> Testing
> ---
> 
> precheckin testing is underway
> 
> 
> Thanks,
> 
> Bruce Schuchardt
> 
>

[GitHub] incubator-geode pull request: Geode-54: missing javadocs

2016-03-18 Thread sbawaska

Github user sbawaska commented on the pull request:

https://github.com/apache/incubator-geode/pull/115#issuecomment-197601802
  
+1
I will merge this in.
CI failed because .travis.yml file does not exist on the asf-site branch.


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

Review Request 44936: Changed references of off-heap compaction to defragmentation

2016-03-18 Thread Sai Boorlagadda


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

Review request for geode and Darrel Schneider.


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


Repository: geode


Description
---

Changed references of off-heap compaction to defragmentation


Diffs
-

  geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/Fragment.java 
0ea6cf84090912957124b471901a46f49c6fd51c 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 c943a7e934db1eff74df9299e52378a6f6b6eba1 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorImpl.java
 2050dd4e82ec128ae4c60eb2a815d014ca7fadf5 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapMemoryStats.java
 790e43df870e9c32aa718c0c883e4ab567dd824b 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
 2bdcfba4be05a8f069997c63d374def516b33689 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/beans/MemberMBeanBridge.java
 61e328d0d632cf760fd1d7d3ee7833833b596891 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
 950d90be8491d4316147a49c1fd0b662ad340fd2 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorFillPatternJUnitTest.java
 f1d223dbd1a621073b5be7140b5a07adc50da957 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorJUnitTest.java
 7639f8d125e74d4bf78940c901c689cec1804107 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/NullOffHeapMemoryStats.java
 88bab77c90e285941b1ef04db65177e6fbf9cbcd 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapRegionBase.java
 fb1aa41fd5ffbc746eb31dabf4d2c15850fa9c4c 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapStorageJUnitTest.java
 d30d4c44d0d7141584aaadf4193e2da43746c63c 

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


Testing
---


Thanks,

Sai Boorlagadda

Re: [DISCUSS] Remove setCustomEvictionAttributes that came in with HDFS changes from develop?

2016-03-18 Thread robert geiger

+1

Also would like to see the storage layer move to a pluggable model for stores 
other than disk (we would like to contribute this). Would be willing to take on 
the work of turing HDFS into a separate pluggable module as part of this 
effort. If responses are positive will open a Jira to capture the pluggable 
store proposal.

Bob



On 3/18/16, 4:15 PM, "William Markito"  wrote:

>+1 to move it to "HDFS feature branch".  I'd rather have a eviction
>class(es) specific to HDFS.
>
>On Fri, Mar 18, 2016 at 4:03 PM, Dan Smith  wrote:
>
>> While looking to the HDFS related changes, I noticed that a new custom
>> eviction feature was also added related to those changes. Unlike the
>> already existing CustomExpiry which returns an expiration time for a single
>> key, this takes an EvictionCriteria that is polled periodically and returns
>> return a list of keys to evict.
>>
>> I noticed we currently have no tests for this so I'm not sure if it
>> actually works or not. Is this something we actually want in geode or
>> should it get removed? My inclination is to move to the HDFS branch,
>> asssuming we create one, since it came in with that functionality. And then
>> not merge it back to develop until there are tests associated with it.
>>
>> -Dan
>>
>> /**
>>* Set custom {@link EvictionCriteria} for the region with start time and
>>* interval of evictor task to be run in milliseconds, or evict incoming
>> rows
>>* in case both start and frequency are specified as zero.
>>*
>>* @param criteria
>>*  an {@link EvictionCriteria} to be used for eviction for HDFS
>>*  persistent regions
>>* @param start
>>*  the start time at which periodic evictor task should be first
>>*  fired to apply the provided {@link EvictionCriteria}; if this
>> is
>>*  zero then current time is used for the first invocation of
>> evictor
>>* @param interval
>>*  the periodic frequency at which to run the evictor task after
>> the
>>*  initial start; if this is if both start and frequency are
>> zero
>>*  then {@link EvictionCriteria} is applied on incoming
>> insert/update
>>*  to determine whether it is to be retained
>>*/
>>   public RegionFactory setCustomEvictionAttributes(
>>   EvictionCriteria criteria, long start, long interval) {
>>
>> /**
>>  * Interface implemented by an EVICTION BY CRITERIA of
>>  * {@link CustomEvictionAttributes}. This will be invoked by periodic
>> evictor
>>  * task that will get the keys to be evicted using this and then destroy
>> from
>>  * the region to which this is attached.
>>  *
>>  * @author swale
>>  * @since gfxd 1.0
>>  */
>> public interface EvictionCriteria {
>>
>>   /**
>>* Get the (key, routing object) of the entries to be evicted from region
>>* satisfying EVICTION BY CRITERIA at this point of time.
>>* 
>>* The returned Map.Entry object by the Iterator may be reused internally
>> so
>>* caller must extract the key, routing object from the entry on each
>>* iteration.
>>*/
>>   Iterator> getKeysToBeEvicted(long currentMillis,
>>   Region region);
>>
>>   /**
>>* Last moment check if an entry should be evicted or not applying the
>>* EVICTION BY CRITERIA again under the region entry lock in case the
>> entry
>>* has changed after the check in {@link #getKeysToBeEvicted}.
>>*/
>>   boolean doEvict(EntryEvent event);
>>
>>   /**
>>* Return true if this eviction criteria is equivalent to the other one.
>> This
>>* is used to ensure that custom eviction is configured identically on
>> all the
>>* nodes of a cluster hosting the region to which this eviction criteria
>> has
>>* been attached.
>>*/
>>   boolean isEquivalent(EvictionCriteria other);
>> }
>>
>
>
>
>-- 
>
>~/William

Review Request 45053: GEODE-936 test is seeing DistributedSystemDisconnectedException exception

2016-03-18 Thread Hitesh Khamesra


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

Review request for geode, Bruce Schuchardt and Dan Smith.


Repository: geode


Description
---

As we are disconnecting while taking lock we may see 
DistributedSystemDisconnectedException exception. Catched in test and ignored


Diffs
-

  
geode-core/src/test/java/com/gemstone/gemfire/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
 bc3bee6 

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


Testing
---


Thanks,

Hitesh Khamesra

Re: [DISCUSS] M2 issues - what's included and how we're tracking them

2016-03-18 Thread Dan Smith

It sounds like we have consensus on using the fix version to track what's
in the release. I'll update the fix version on the tickets that don't have
it and change the query for the wiki page. I think there is some consensus
for pushing out the subtasks GEODE-818, so I'll update those to not be in
M2.

I also like the idea of time based releases. I think that argues for not
marking things as "in scope" for a release, but instead just prioritizing
them. Or at least only marking a minimal set of things as "must fix" for M2.

Since we're talking about time scope, what date do we want to target for
starting a vote for M2? It's been about 7 weeks since M1, so maybe should
we target about a week from now - Friday, March 25?

If we do that, I think we should remove a few more things from the "Must
Fix" list:
GEODE-33 Create project examples
GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)

-Dan

On Fri, Mar 18, 2016 at 1:28 PM, Edin Zulich  wrote:

> + 1 for fix version
>
> +1 one for moving out the larger tasks and releasing sooner
>
> > On Mar 18, 2016, at 12:04 PM, Dan Smith  wrote:
> >
> > I'll take the blame for the sub-tasks of GEODE-818 - I created those as I
> > was working on GEODE-27 and found parts of the code that need cleaning
> up.
> > But some of those tasks are rather large, so we should probably move them
> > out.
> >
> >
> > On Fri, Mar 18, 2016 at 9:45 AM, Nitin Lamba  wrote:
> >
> >> +1 for fixed version
> >>
> >> Typical JIRA workflow would expect the Assignee to put fixed version
> AFTER
> >> the issue is resolved. There's another field 'Target Version' which is
> used
> >> for planning, however, in the interest of simplicity, we can use Fixed
> >> Version.
> >>
> >> As for M2, we already have a lot of new features going-in (wan, cq,
> pulse,
> >> etc) so we could fix only high-priority items (POM, artifacts, etc) and
> >> remove any new items that haven't been started yet, and prepare for a
> >> release.
> >>
> >> +1 for Anil's proposal
> >>
> >> He brings-up an important question about release cadence - time or
> scope?
> >> My view is for a time-based release that creates an execution rhythm
> >> (release early/often). This would also utilize agile/ sprint mechanisms
> >> available in JIRA.
> >>
> >> How about 6 weeks of dev (feature, bug squashing, etc) and 2 weeks of
> >> release hardening (prep/review/vote)? May need a different thread than
> M2.
> >>
> >> Nitin
> >>
> >> On Fri, Mar 18, 2016 at 9:03 AM, Anilkumar Gingade  >
> >> wrote:
> >>
> >>> +1 fixed version...
> >>>
> >>> About what we need to include, depends on time-line (if any) and scope
> of
> >>> the release (based on requirement)...
> >>>
> >>> If there is no time-line and there is no specific requirement, we can
> >> take
> >>> balanced approach...Have a release time (approximate); identify tickets
> >>> that can be fixed
> >>>
> >>> GEODE-1072 can be big chunk of work...Or most of sub-project in
> >>> GEODE-818...
> >>>
> >>> -Anil.
> >>>
> >>>
> >>>
> >>> On Thu, Mar 17, 2016 at 9:12 PM, Anthony Baker 
> >> wrote:
> >>>
>  +1 for fix version
> 
>  Anthony
> 
> > On Mar 17, 2016, at 8:55 PM, William Markito 
>  wrote:
> >
> > +1 to use "Fix Version".  This also helps with release notes
>  auto-generated
> > by JIRA.
> >
> > About the scope, I'd push for M3 at least GEODE-33 and rather release
> > sooner...
> >
> >
> >> On Thu, Mar 17, 2016 at 5:31 PM, Dan Smith 
> >> wrote:
> >>
> >> Hi folks,
> >>
> >> We currently have 17 open M2 issues marked with "Sprint" M2, and 14
> >> of
> >> those are also marked with "Fix Version" M2. Which of these issues
> >> do
> >>> we
> >> actually want to try to get into M2 at this point, and what do we
> >> want
>  to
> >> push out?
> >>
> >> As far as tracking the issues go I think we should settle on a
> >> single
> >> convention: either the sprint field or the fix version field. What
>  field do
> >> people want to use?
> >>
> >> M2 Wiki Page:
> >>
> >>
> 
> >>>
> >>
> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M2+%28Second%29+Release
> >>
> >> Issues with M2 as the Sprint
> >> https://issues.apache.org/jira/issues/?filter=12334915
> >>
> >> GEODE-27 Apache Geode POM file(s) are incorrect!
> >> GEODE-386 Change xsd namespace to apache
> >> GEODE-33 Create project examples
> >> GEODE-1075 GEODE-818 Move Admin REST API code into the geode-web
> >> project
> >> GEODE-1072 GEODE-818 Move HDFS code to it's own subproject and
> >> get
>  rid
> >> of HDFS dependencies in gemfire-core
> >> GEODE-1080 GEODE-818 Move JettyHelper and related classes to a
> >> subproject
> >>

Re: [DISCUSS] Remove setCustomEvictionAttributes that came in with HDFS changes from develop?

2016-03-18 Thread Dan Smith

Hi Bob,

Pluggable persistence sounds like a great feature! Help cleaning up this
HDFS feature to be more pluggable is also most welcome :)

I'm interested to hear more about what your ideas are for pluggable
persistence - such as whether you're thinking about swapping out the
persistence at an individual node level (redundancy is still managed be
geode) or at the cluster level (like this HDFS layer, redundancy of the
persistent data is managed elsewhere). I'd love to see your proposal!

-Dan

On Fri, Mar 18, 2016 at 4:24 PM, robert geiger  wrote:

> +1
>
> Also would like to see the storage layer move to a pluggable model for
> stores other than disk (we would like to contribute this). Would be willing
> to take on the work of turing HDFS into a separate pluggable module as part
> of this effort. If responses are positive will open a Jira to capture the
> pluggable store proposal.
>
> Bob
>
>
>
> On 3/18/16, 4:15 PM, "William Markito"  wrote:
>
> >+1 to move it to "HDFS feature branch".  I'd rather have a eviction
> >class(es) specific to HDFS.
> >
> >On Fri, Mar 18, 2016 at 4:03 PM, Dan Smith  wrote:
> >
> >> While looking to the HDFS related changes, I noticed that a new custom
> >> eviction feature was also added related to those changes. Unlike the
> >> already existing CustomExpiry which returns an expiration time for a
> single
> >> key, this takes an EvictionCriteria that is polled periodically and
> returns
> >> return a list of keys to evict.
> >>
> >> I noticed we currently have no tests for this so I'm not sure if it
> >> actually works or not. Is this something we actually want in geode or
> >> should it get removed? My inclination is to move to the HDFS branch,
> >> asssuming we create one, since it came in with that functionality. And
> then
> >> not merge it back to develop until there are tests associated with it.
> >>
> >> -Dan
> >>
> >> /**
> >>* Set custom {@link EvictionCriteria} for the region with start time
> and
> >>* interval of evictor task to be run in milliseconds, or evict
> incoming
> >> rows
> >>* in case both start and frequency are specified as zero.
> >>*
> >>* @param criteria
> >>*  an {@link EvictionCriteria} to be used for eviction for
> HDFS
> >>*  persistent regions
> >>* @param start
> >>*  the start time at which periodic evictor task should be
> first
> >>*  fired to apply the provided {@link EvictionCriteria}; if
> this
> >> is
> >>*  zero then current time is used for the first invocation of
> >> evictor
> >>* @param interval
> >>*  the periodic frequency at which to run the evictor task
> after
> >> the
> >>*  initial start; if this is if both start and frequency are
> >> zero
> >>*  then {@link EvictionCriteria} is applied on incoming
> >> insert/update
> >>*  to determine whether it is to be retained
> >>*/
> >>   public RegionFactory setCustomEvictionAttributes(
> >>   EvictionCriteria criteria, long start, long interval) {
> >>
> >> /**
> >>  * Interface implemented by an EVICTION BY CRITERIA of
> >>  * {@link CustomEvictionAttributes}. This will be invoked by periodic
> >> evictor
> >>  * task that will get the keys to be evicted using this and then destroy
> >> from
> >>  * the region to which this is attached.
> >>  *
> >>  * @author swale
> >>  * @since gfxd 1.0
> >>  */
> >> public interface EvictionCriteria {
> >>
> >>   /**
> >>* Get the (key, routing object) of the entries to be evicted from
> region
> >>* satisfying EVICTION BY CRITERIA at this point of time.
> >>* 
> >>* The returned Map.Entry object by the Iterator may be reused
> internally
> >> so
> >>* caller must extract the key, routing object from the entry on each
> >>* iteration.
> >>*/
> >>   Iterator> getKeysToBeEvicted(long currentMillis,
> >>   Region region);
> >>
> >>   /**
> >>* Last moment check if an entry should be evicted or not applying the
> >>* EVICTION BY CRITERIA again under the region entry lock in case the
> >> entry
> >>* has changed after the check in {@link #getKeysToBeEvicted}.
> >>*/
> >>   boolean doEvict(EntryEvent event);
> >>
> >>   /**
> >>* Return true if this eviction criteria is equivalent to the other
> one.
> >> This
> >>* is used to ensure that custom eviction is configured identically on
> >> all the
> >>* nodes of a cluster hosting the region to which this eviction
> criteria
> >> has
> >>* been attached.
> >>*/
> >>   boolean isEquivalent(EvictionCriteria other);
> >> }
> >>
> >
> >
> >
> >--
> >
> >~/William
>

[DISCUSS] Remove setCustomEvictionAttributes that came in with HDFS changes from develop?

2016-03-18 Thread Dan Smith

While looking to the HDFS related changes, I noticed that a new custom
eviction feature was also added related to those changes. Unlike the
already existing CustomExpiry which returns an expiration time for a single
key, this takes an EvictionCriteria that is polled periodically and returns
return a list of keys to evict.

I noticed we currently have no tests for this so I'm not sure if it
actually works or not. Is this something we actually want in geode or
should it get removed? My inclination is to move to the HDFS branch,
asssuming we create one, since it came in with that functionality. And then
not merge it back to develop until there are tests associated with it.

-Dan

/**
   * Set custom {@link EvictionCriteria} for the region with start time and
   * interval of evictor task to be run in milliseconds, or evict incoming
rows
   * in case both start and frequency are specified as zero.
   *
   * @param criteria
   *  an {@link EvictionCriteria} to be used for eviction for HDFS
   *  persistent regions
   * @param start
   *  the start time at which periodic evictor task should be first
   *  fired to apply the provided {@link EvictionCriteria}; if this
is
   *  zero then current time is used for the first invocation of
evictor
   * @param interval
   *  the periodic frequency at which to run the evictor task after
the
   *  initial start; if this is if both start and frequency are zero
   *  then {@link EvictionCriteria} is applied on incoming
insert/update
   *  to determine whether it is to be retained
   */
  public RegionFactory setCustomEvictionAttributes(
  EvictionCriteria criteria, long start, long interval) {

/**
 * Interface implemented by an EVICTION BY CRITERIA of
 * {@link CustomEvictionAttributes}. This will be invoked by periodic
evictor
 * task that will get the keys to be evicted using this and then destroy
from
 * the region to which this is attached.
 *
 * @author swale
 * @since gfxd 1.0
 */
public interface EvictionCriteria {

  /**
   * Get the (key, routing object) of the entries to be evicted from region
   * satisfying EVICTION BY CRITERIA at this point of time.
   * 
   * The returned Map.Entry object by the Iterator may be reused internally
so
   * caller must extract the key, routing object from the entry on each
   * iteration.
   */
  Iterator> getKeysToBeEvicted(long currentMillis,
  Region region);

  /**
   * Last moment check if an entry should be evicted or not applying the
   * EVICTION BY CRITERIA again under the region entry lock in case the
entry
   * has changed after the check in {@link #getKeysToBeEvicted}.
   */
  boolean doEvict(EntryEvent event);

  /**
   * Return true if this eviction criteria is equivalent to the other one.
This
   * is used to ensure that custom eviction is configured identically on
all the
   * nodes of a cluster hosting the region to which this eviction criteria
has
   * been attached.
   */
  boolean isEquivalent(EvictionCriteria other);
}

Re: source code build instruction improvements on the cwiki

2016-03-18 Thread William Markito

Thank you Karen, looks good!

On Fri, Mar 18, 2016 at 4:20 PM, Karen Miller  wrote:

> Check out improvements to the cwiki page on building Geode from source at
>
> https://cwiki.apache.org/confluence/display/GEODE/Building+and+Running+Geode+from+Source
>
> I've also refined the Geode In 5 Minutes guide found at
> https://cwiki.apache.org/confluence/display/GEODE/Index
>
> Please consider and provide feedback.  Karen
>



-- 

~/William

Re: source code build instruction improvements on the cwiki

2016-03-18 Thread Dan Smith

build depends on installDist so I think "build installDist" is redundant.
It should be just
./gradlew build
or
./gradlew build -Dskip.tests=true

There is a gradlew.bat script for windows if you actually clone the source.
Should we tell people that only need to install gradle if they download the
source distribution?

-Dan

On Fri, Mar 18, 2016 at 4:20 PM, Karen Miller  wrote:

> Check out improvements to the cwiki page on building Geode from source at
>
> https://cwiki.apache.org/confluence/display/GEODE/Building+and+Running+Geode+from+Source
>
> I've also refined the Geode In 5 Minutes guide found at
> https://cwiki.apache.org/confluence/display/GEODE/Index
>
> Please consider and provide feedback.  Karen
>

source code build instruction improvements on the cwiki

2016-03-18 Thread Karen Miller

Check out improvements to the cwiki page on building Geode from source at
https://cwiki.apache.org/confluence/display/GEODE/Building+and+Running+Geode+from+Source

I've also refined the Geode In 5 Minutes guide found at
https://cwiki.apache.org/confluence/display/GEODE/Index

Please consider and provide feedback.  Karen

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

2016-03-18 Thread Spring CI


---
Spring Data GemFire > Nightly-ApacheGeode > #254 was successful.
---
Scheduled
1346 tests in total.

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





--
This message is automatically generated by Atlassian Bamboo

Re: Review Request 44936: Changed references of off-heap compaction to defragmentation

2016-03-18 Thread Darrel Schneider


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


Ship it!




Ship It!

- Darrel Schneider


On March 16, 2016, 4:30 p.m., Sai Boorlagadda wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44936/
> ---
> 
> (Updated March 16, 2016, 4:30 p.m.)
> 
> 
> Review request for geode and Darrel Schneider.
> 
> 
> Bugs: GEODE-1017
> https://issues.apache.org/jira/browse/GEODE-1017
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> Changed references of off-heap compaction to defragmentation
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/Fragment.java 
> 0ea6cf84090912957124b471901a46f49c6fd51c 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
>  c943a7e934db1eff74df9299e52378a6f6b6eba1 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorImpl.java
>  2050dd4e82ec128ae4c60eb2a815d014ca7fadf5 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapMemoryStats.java
>  790e43df870e9c32aa718c0c883e4ab567dd824b 
>   
> geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
>  2bdcfba4be05a8f069997c63d374def516b33689 
>   
> geode-core/src/main/java/com/gemstone/gemfire/management/internal/beans/MemberMBeanBridge.java
>  61e328d0d632cf760fd1d7d3ee7833833b596891 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
>  950d90be8491d4316147a49c1fd0b662ad340fd2 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorFillPatternJUnitTest.java
>  f1d223dbd1a621073b5be7140b5a07adc50da957 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorJUnitTest.java
>  7639f8d125e74d4bf78940c901c689cec1804107 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/NullOffHeapMemoryStats.java
>  88bab77c90e285941b1ef04db65177e6fbf9cbcd 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapRegionBase.java
>  fb1aa41fd5ffbc746eb31dabf4d2c15850fa9c4c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapStorageJUnitTest.java
>  d30d4c44d0d7141584aaadf4193e2da43746c63c 
> 
> Diff: https://reviews.apache.org/r/44936/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Sai Boorlagadda
> 
>

cache.tier.sockets dunit tests have setup with sleep

2016-03-18 Thread Kirk Lund

I'm seeing lots of cache.tier.sockets dunit tests that have a setup method
which disconnectsAllFromDS() and then sleeps for 5 or 10 seconds before
continuing. Is there a valid reason for these tests to sleep at that point?
And if I were to change this to use Awaitility what condition would I need
to check for? In other words, why are they sleeping?

public RegisterInterestKeysDUnitTest(String name) {
  super(name);
}

@Override
public final void postSetUp() throws Exception {
  disconnectAllFromDS();
  Wait.pause(5000);

  final Host host = Host.getHost(0);
  //Server1 VM
  server1 = host.getVM(0);

  //Server2 VM
  server2 = host.getVM(1);

  //Client 1 VM
  client1 = host.getVM(2);

  //client 2 VM
  client2 = host.getVM(3);

  createImpl();
  for (int i=0; i<4; i++) {
host.getVM(i).invoke(getClass(), "createImpl", null);
  }


-Kirk

Re: Review Request 45053: GEODE-936 test is seeing DistributedSystemDisconnectedException exception

2016-03-18 Thread Bruce Schuchardt


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


Ship it!




Ship It!

- Bruce Schuchardt


On March 18, 2016, 9:45 p.m., Hitesh Khamesra wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/45053/
> ---
> 
> (Updated March 18, 2016, 9:45 p.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Dan Smith.
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> As we are disconnecting while taking lock we may see 
> DistributedSystemDisconnectedException exception. Catched in test and ignored
> 
> 
> Diffs
> -
> 
>   
> geode-core/src/test/java/com/gemstone/gemfire/distributed/internal/deadlock/GemFireDeadlockDetectorDUnitTest.java
>  bc3bee6 
> 
> Diff: https://reviews.apache.org/r/45053/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Hitesh Khamesra
> 
>

Re: Review Request 44936: Changed references of off-heap compaction to defragmentation

2016-03-18 Thread Sai Boorlagadda


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

(Updated March 16, 2016, 11:30 p.m.)


Review request for geode and Darrel Schneider.


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


Repository: geode


Description
---

Changed references of off-heap compaction to defragmentation


Diffs (updated)
-

  geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/Fragment.java 
0ea6cf84090912957124b471901a46f49c6fd51c 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/FreeListManager.java
 c943a7e934db1eff74df9299e52378a6f6b6eba1 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorImpl.java
 2050dd4e82ec128ae4c60eb2a815d014ca7fadf5 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapMemoryStats.java
 790e43df870e9c32aa718c0c883e4ab567dd824b 
  
geode-core/src/main/java/com/gemstone/gemfire/internal/offheap/OffHeapStorage.java
 2bdcfba4be05a8f069997c63d374def516b33689 
  
geode-core/src/main/java/com/gemstone/gemfire/management/internal/beans/MemberMBeanBridge.java
 61e328d0d632cf760fd1d7d3ee7833833b596891 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/FreeListManagerTest.java
 950d90be8491d4316147a49c1fd0b662ad340fd2 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorFillPatternJUnitTest.java
 f1d223dbd1a621073b5be7140b5a07adc50da957 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/MemoryAllocatorJUnitTest.java
 7639f8d125e74d4bf78940c901c689cec1804107 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/NullOffHeapMemoryStats.java
 88bab77c90e285941b1ef04db65177e6fbf9cbcd 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapRegionBase.java
 fb1aa41fd5ffbc746eb31dabf4d2c15850fa9c4c 
  
geode-core/src/test/java/com/gemstone/gemfire/internal/offheap/OffHeapStorageJUnitTest.java
 d30d4c44d0d7141584aaadf4193e2da43746c63c 

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


Testing
---


Thanks,

Sai Boorlagadda

Re: GEODE-949

2016-03-18 Thread Bruce Schuchardt


The Apache build from 18 March had these failures:

 
com.gemstone.gemfire.distributed.internal.streaming.StreamingOperationManyDUnitTest.testStreamingManyProvidersNoExceptions
 47 ms1
 
com.gemstone.gemfire.internal.cache.execute.DistributedRegionFunctionExecutionDUnitTest.testBug41367
 11 sec1
 
com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest.testDistributedRegionClientPutRejection

https://builds.apache.org/job/Geode-nightly/412/testReport/

Le 3/18/2016 1:07 PM, Kirk Lund a écrit :

There were three dunit failures in the nightly build last night:

Test Result

(3
failures / ±0)

-

com.gemstone.gemfire.internal.cache.tier.sockets.UpdatePropagationDUnitTest.testVerifyUpdatesReceivedByOtherClients


-

com.gemstone.gemfire.internal.cache.execute.DistributedRegionFunctionExecutionDUnitTest.testBug41367


-

com.gemstone.gemfire.cache.management.MemoryThresholdsDUnitTest.testDistributedRegionClientPutRejection




DistributedRegionFunctionExecutionDUnitTest.testBug41367 was caused by my
fix for GEODE-949. I followed up with filing GEODE-1112 and committed the
fix. This test is now passing again.

-Kirk


On Fri, Mar 18, 2016 at 10:05 AM, Kirk Lund  wrote:


Looks like most of the affected dunit tests are ones that are currently
"DISABLED" for whatever reasons :/ On one hand that's good because it means
nobodies precheckin will fail but it's bad because these tests aren't being
run.

The problem with these "tests" is that they are using String reflection to
refer to classes that I moved to a different package and somehow these
spots were missed by the refactoring tool.

-Kirk


On Fri, Mar 18, 2016 at 10:01 AM, Kirk Lund  wrote:


Looks like some dunit tests are failing due to the commit of GEODE-949. I
ran precheckin multiple times on feature/GEODE-949-2 before merging to
develop, so I'm not sure how this happened. I'm working on fixing up the
broken dunit tests and will commit these to develop soon.

-Kirk

Re: Review Request 44995: GEODE-1050: add JUnit 4 versions of DistributedTestCase and CacheTestCase

2016-03-18 Thread William Markito


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


Ship it!




Awesome clean up Kirk!

- William Markito


On March 18, 2016, 4:29 p.m., Kirk Lund wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/44995/
> ---
> 
> (Updated March 18, 2016, 4:29 p.m.)
> 
> 
> Review request for geode, Jens Deppe, Jinmei Liao, and William Markito.
> 
> 
> Bugs: GEODE-1050
> https://issues.apache.org/jira/browse/GEODE-1050
> 
> 
> Repository: geode
> 
> 
> Description
> ---
> 
> GEODE-1050: add JUnit 4 versions of DistributedTestCase and CacheTestCase
> 
> * refactor DistributedTestCase into two implementations that delegate: 
> JUnit3DistributedTestCase and JUnit4DistributedTestCase
> * refactor CacheTestCase into two implementations that delegate: 
> JUnit3CacheTestCase and JUnit4CacheTestCase
> * refactor super.setUp() hierarchy into template method chain like tearDown()
> * change all variables in CacheTestCase and DistributedTestCase to private 
> and use methods to access them
> * change some tests to use getDistributedSystemProperties() and getSystem()
> 
> 
> Diffs
> -
> 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/management/internal/cli/commands/LauncherLifecycleCommandsDUnitTest.java
>  f0eaaac 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIOnRegionFunctionExecutionDUnitTest.java
>  ed622e8 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPITestBase.java
>  ba709b7 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIsAndInterOpsDUnitTest.java
>  0245fa0 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIsOnGroupsFunctionExecutionDUnitTest.java
>  0419c78 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIsOnMembersFunctionExecutionDUnitTest.java
>  f8bf20e 
>   
> geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIsWithSSLDUnitTest.java
>  29aab32 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/CacheRegionClearStatsDUnitTest.java
>  88a32a3 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/ClientServerTimeSyncDUnitTest.java
>  8b04ab5 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/ConnectionPoolAndLoaderDUnitTest.java
>  ee382ab 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/ConnectionPoolAutoDUnitTest.java
>  bf5a22c 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/ConnectionPoolDUnitTest.java
>  e09a4c9 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/ClientServerRegisterInterestsDUnitTest.java
>  58844b0 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/AutoConnectionSourceDUnitTest.java
>  03368de 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/CacheServerSSLConnectionDUnitTest.java
>  c59ed4f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/LocatorTestBase.java
>  a89d648 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/client/internal/SSLNoClientAuthDUnitTest.java
>  e23fb76 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/management/MemoryThresholdsDUnitTest.java
>  c93848b 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/management/MemoryThresholdsOffHeapDUnitTest.java
>  3cf7b09 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/CompactRangeIndexDUnitTest.java
>  81b545f 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/HashIndexDUnitTest.java
>  38721be 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/QueryDataInconsistencyDUnitTest.java
>  0227836 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/QueryIndexUsingXMLDUnitTest.java
>  5e9df71 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/QueryUsingFunctionContextDUnitTest.java
>  1e3e973 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/QueryUsingPoolDUnitTest.java
>  4df1f81 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/RemoteQueryDUnitTest.java
>  09fd945 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/dunit/ResourceManagerWithQueryMonitorDUnitTest.java
>  85ae9aa 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/index/ConcurrentIndexUpdateWithInplaceObjectModFalseDUnitTest.java
>  6cbbef2 
>   
> geode-core/src/test/java/com/gemstone/gemfire/cache/query/internal/index/ConcurrentIndexUpdateWithoutWLDUnitTest.java
>  2ac564a 
>   
>

Re: cache.tier.sockets dunit tests have setup with sleep

2016-03-18 Thread Bruce Schuchardt

I think you should take out the waits.  If disconnectAllFromDS() is 
returning before things have shut down it should be fixed.


Le 3/18/2016 1:42 PM, Kirk Lund a écrit :

I'm seeing lots of cache.tier.sockets dunit tests that have a setup method
which disconnectsAllFromDS() and then sleeps for 5 or 10 seconds before
continuing. Is there a valid reason for these tests to sleep at that point?
And if I were to change this to use Awaitility what condition would I need
to check for? In other words, why are they sleeping?

public RegisterInterestKeysDUnitTest(String name) {
   super(name);
}

@Override
public final void postSetUp() throws Exception {
   disconnectAllFromDS();
   Wait.pause(5000);

   final Host host = Host.getHost(0);
   //Server1 VM
   server1 = host.getVM(0);

   //Server2 VM
   server2 = host.getVM(1);

   //Client 1 VM
   client1 = host.getVM(2);

   //client 2 VM
   client2 = host.getVM(3);

   createImpl();
   for (int i=0; i<4; i++) {
 host.getVM(i).invoke(getClass(), "createImpl", null);
   }


-Kirk

Re: [DISCUSS] Remove setCustomEvictionAttributes that came in with HDFS changes from develop?

2016-03-18 Thread William Markito

+1 to move it to "HDFS feature branch".  I'd rather have a eviction
class(es) specific to HDFS.

On Fri, Mar 18, 2016 at 4:03 PM, Dan Smith  wrote:

> While looking to the HDFS related changes, I noticed that a new custom
> eviction feature was also added related to those changes. Unlike the
> already existing CustomExpiry which returns an expiration time for a single
> key, this takes an EvictionCriteria that is polled periodically and returns
> return a list of keys to evict.
>
> I noticed we currently have no tests for this so I'm not sure if it
> actually works or not. Is this something we actually want in geode or
> should it get removed? My inclination is to move to the HDFS branch,
> asssuming we create one, since it came in with that functionality. And then
> not merge it back to develop until there are tests associated with it.
>
> -Dan
>
> /**
>* Set custom {@link EvictionCriteria} for the region with start time and
>* interval of evictor task to be run in milliseconds, or evict incoming
> rows
>* in case both start and frequency are specified as zero.
>*
>* @param criteria
>*  an {@link EvictionCriteria} to be used for eviction for HDFS
>*  persistent regions
>* @param start
>*  the start time at which periodic evictor task should be first
>*  fired to apply the provided {@link EvictionCriteria}; if this
> is
>*  zero then current time is used for the first invocation of
> evictor
>* @param interval
>*  the periodic frequency at which to run the evictor task after
> the
>*  initial start; if this is if both start and frequency are
> zero
>*  then {@link EvictionCriteria} is applied on incoming
> insert/update
>*  to determine whether it is to be retained
>*/
>   public RegionFactory setCustomEvictionAttributes(
>   EvictionCriteria criteria, long start, long interval) {
>
> /**
>  * Interface implemented by an EVICTION BY CRITERIA of
>  * {@link CustomEvictionAttributes}. This will be invoked by periodic
> evictor
>  * task that will get the keys to be evicted using this and then destroy
> from
>  * the region to which this is attached.
>  *
>  * @author swale
>  * @since gfxd 1.0
>  */
> public interface EvictionCriteria {
>
>   /**
>* Get the (key, routing object) of the entries to be evicted from region
>* satisfying EVICTION BY CRITERIA at this point of time.
>* 
>* The returned Map.Entry object by the Iterator may be reused internally
> so
>* caller must extract the key, routing object from the entry on each
>* iteration.
>*/
>   Iterator> getKeysToBeEvicted(long currentMillis,
>   Region region);
>
>   /**
>* Last moment check if an entry should be evicted or not applying the
>* EVICTION BY CRITERIA again under the region entry lock in case the
> entry
>* has changed after the check in {@link #getKeysToBeEvicted}.
>*/
>   boolean doEvict(EntryEvent event);
>
>   /**
>* Return true if this eviction criteria is equivalent to the other one.
> This
>* is used to ensure that custom eviction is configured identically on
> all the
>* nodes of a cluster hosting the region to which this eviction criteria
> has
>* been attached.
>*/
>   boolean isEquivalent(EvictionCriteria other);
> }
>



-- 

~/William

Converting a DUnit test from JUnit 3 to JUnit 4

2016-03-18 Thread Kirk Lund

 Converting a DUnit test from JUnit 3 to JUnit 4:

1) extend *JUnit4DistributedTestCase* or *JUnit4CacheTestCase*
2) remove constructor(String name)
3) *import static com.gemstone.gemfire.test.dunit.Assert.*;*
4) annotate test class directly with *@Category(DistributedTest.class)*
5) annotate all test methods with *@Test* (even the disabled ones!)
6) annotate disabled test methods with *@Ignore(“include bug # and/or
comment”)*
7) remove *import junit.framework.AssertionFailedError*
8) replace any custom usage of *AssertionFailedError* with *AssertionError*

After committing GEODE-1050 to develop, you can now convert any DUnit test
from JUnit 3 to JUnit 4 by following the above steps.

I’ve already converted the following as examples:

geode-core/src/test/java/com/gemstone/gemfire/cache30/CacheCloseDUnitTest.java
geode-core/src/test/java/com/gemstone/gemfire/cache30/CachedAllEventsDUnitTest.java
geode-core/src/test/java/com/gemstone/gemfire/distributed/DistributedMemberDUnitTest.java
geode-core/src/test/java/com/gemstone/gemfire/distributed/DistributedSystemDUnitTest.java

The JUnit3 and JUnit4 implementation classes are currently under
com.gemstone.gemfire.test.dunit.internal.*. Now that I everything merged to
develop I’ll probably follow up with a bit more refactoring but I'd like to
hear feedback from others first.

-Kirk

Review Request 45058: GEODE-1107 CI failure: RestAPIsWithSSLDUnitTest.testSimpleSSL

2016-03-18 Thread Jianxia Chen


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

Review request for geode, Bruce Schuchardt, Hitesh Khamesra, and Udo Kohlmeyer.


Repository: geode


Description
---

Set jmx-manager-port to 0 so that it does not allow remote client connections. 
Hence avoid starting the agent. Then there is no worry about the port already 
in use for the agent. HTTP service is still started though.


Diffs
-

  
geode-assembly/src/test/java/com/gemstone/gemfire/rest/internal/web/controllers/RestAPIsWithSSLDUnitTest.java
 29aab32 

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


Testing
---

RestAPIsWithSSLDUnitTest


Thanks,

Jianxia Chen

38 matches

Mail list logo